Category: Uncategorized

By Sam Stemler

ADA lawsuits concerning web accessibility increased 177% from 2017 to 2018, from 814 to 2258. This number is set to increase again in 2019. As more and more businesses land in civil court, it’s led many business owners to wonder; Do all websites have to be ADA compliant? Does my website have to ADA compliant? The answer is not so clear.

Do All Websites Have to Be ADA Compliant?

Do all websites have to be ADA compliant? Technically, the Americans with Disabilities Act (ADA) Title III, which concerns public businesses, does not specifically address websites. Local and state government websites must be accessible under Title II of the ADA and Section 508 of the Rehabilitation Act. However, ADA civil suits have been brought against businesses with inaccessible websites, and courts have ordered some businesses to make their websites accessible.

What does this mean? ADA legislation as is applies to websites is currently a gray area. This often leaves the interpretation of the law up to the court where the lawsuit is filed, generally a state court. Suits have been filed in every state, though the majority of cases are in New York, Florida, California, Pennsylvania and Massachusetts.

Do all websites have to be ADA compliant? That depends. Courts generally reach one of the following conclusions:

• Yes, a business website is considered a “public accommodation” and must be accessible.
• Yes, but only if the business also has a physical location that serves the public.
• No, the ADA does not specifically address websites and therefore does not apply.

Why is ADA Compliance for Websites Unclear?

It’s well-known that the Americans With Disabilities Act (ADA) requires brick-and-mortar businesses be accessible to all patrons. This includes considerations like wheelchair accessibility and Braille or large print for blind and low-vision patrons, among other things. The ADA references “public accommodations,” and outlines 12 categories that essentially covers all types of public-facing businesses. However, the legislation does not address public-facing websites.

When the ADA was created in 1990, websites were not widely used, so the legislation did not address them. The Act has been updated over the years, but no language was added to address web accessibility. This has left uncertainty as to the question of whether all websites have to be ADA compliant or not.

What If I Lose an ADA Web Accessibility Lawsuit?

Since the ADA does not specifically address web accessibility, it means the Department of Justice (DOJ) will not, at this time, intervene. This means it cannot levy fines or penalties against non-compliant businesses. However, individuals and groups can file civil suits against businesses. If the court rules in the plaintiffs’ favor (the individual or group), the business will be ordered to make their website accessible, and may have to pay the plaintiffs’ attorney fees in some cases. Failure to meet these obligations in the time allotted may result in a civil contempt of court charge or additional legal action by the plaintiff.

When Will the ADA Address Websites?

The DOJ considered addressing web accessibility directly in 2016, but no additional rules or guidance was ever issued. When addressing the matter in 2018 and taking no action, the DOJ referenced Executive Orders issued by President Trump regarding reduced regulations. For the foreseeable future, clarification from the DOJ is unlikely.

These rules nearly made their way to the Supreme Court in 2019. In 2016 a web accessibility civil suit was filed against Dominos Pizza. In the following years, the case filtered through layers of judgements and appeals, and Dominos eventually appealed to the Supreme Court. Unfortunately, the Supreme Court declined the case and returned it to a lower court. Though this provides no final clarification, the ruling by a lower court in favor of the plaintiff supports the legal requirements for web accessibility.

Do all websites have to be ADA compliant? Does yours? Though the legal definitions are somewhat unclear, it is clear that inaccessibility invites legal action and misgivings from customers. Web accessibility does not have to be complex, and it may not take much to test your site and make it accessible. Take web accessibility step by step and you can avoid stressful lawsuits, and invite all patrons to your website.

By Sam Stemler

The Worldwide Web Consortium’s (W3C) Web Content Accessibility Guidelines 2.0 (WCAG 2.0) is the gold standard for assessing web accessibility. Though WCAG 2.0 is outlined on w3.org, some of it can be difficult to understand without web development experience, and the list can be intimidating in itself. We’ve broken down the guidelines into a fast and easy WCAG 2.0 checklist to make your site accessible. This checklist is intended for those without knowledge of web development or programming, and we’ve noted sections where this experience may be required.

WCAG 2.0 Checklist to Make Your Site Accessible

Remember that WCAG 2.0 is not a manual for how your site should be built; rather, it’s a guide for how your site should function. This gives you flexibility about your site, since it isn’t practical or desirable for all websites to look and act the same. Our WCAG 2.0 checklist is intended to help all website managers, content creators and other staff members navigate basic accessibility, but should not be used as a legal guide or tool against accessibility lawsuits. For this checklist, we’ve removed requirements that are somewhat rare or specific, so the WCAG 2.0 checklist addresses only the most common and problematic accessibility issues.

For quick reference, here are the WCAG 2.0 checklist items without explanation. Keep reading to learn more about each item.

• Alternative text or Alt-Text for Pictures
• Headings and Text Are Formatted Properly
• Bold and Italics Are Used to Convey Meaning
• Lists Are Formatted Properly
• Link Text Conveys Links’ Meaning
• Text Color Contrast is 4.5:1 or Better
• Closed Captioning Used on Video and Audio
• Audio and Video Do Not Play Automatically
• Audio and Video Players Have Controls
• Visuals Do Not Flash More Than 3 Times a Second
• Able to Skip Navigation and Blocks
• Images Used in Navigation Have Alternative Text
• Color is Not Required and Navigation Color Contrast is 3:1 or Better
• Site Can Zoom Up to 200%
• Flexible Orientation  
• No Keyboard Traps
• Forms Are Usable With Keyboard and Screenreader
• Hover or Focus Does Not Disrupt Use
• Time-Outs Can Be Extended

Find and fix the most common accessibility issues
Test with Accessible Metrics »

WCAG 2.0 Checklist: For All Web Staff

The following items apply to text, links, and pictures on your site. Many of these items can be programmatically checked by an accessibility testing tool, like Accessible Metrics. Once your site is compliant, everyone who adds content to your site—such as bloggers, photographers or editors—should know and understand these accessibility requirements, so new content is also compliant.

1. Alternative Text or Alt-Text For Pictures

Pictures or infographics should have alternative text (alt-text) which describes the picture. This can be added whenever images are loaded on to the site.

2. Headings and Text Are Formatted Properly

The proper sequence of headings and regular text helps to show how information is organized without a user needing to see the screen. When inputting text, use headings like H1, H2 etc. to divide sections, instead of using bold, underline or other emphasis. Use normal text formatting for regular paragraphs.

3. Bold and Italics Are Used to Convey Meaning

Bold, underline, and italics should be used for semantic purpose, or to show a particular meaning. Use italics to emphasize a word or phrase when it changes the meaning of the sentence. Use bold to emphasize a word as especially important. Do not use italics or bold text simply for visual effect.

4. Lists Are Formatted Properly

If you are making a list, format the list items in either a bulleted or numbered list. Do not simply list each item on its own paragraph. If you do not want to separate the list from the paragraph, use of a colon or semicolon is also suitable.

5. Link Text Conveys Links’ Meaning

When making hyperlinks within the text, the text should accurately show where the link goes. For example, the following link goes to a page on the definition of a hyperlink. Do not use ambiguous link text like “click here” or “more information.”

6. Text Color Contrast is 4.5:1 or Better

Color contrast between text, images and backgrounds should be at least 4.5:1. The traditional black text against a white background and blue link text have adequate contrast. Use accessibility testing tools like a contrast checker before making changes to text colors.

WCAG 2.0 Checklist: For Media Specialists

These checklist items apply to media, like videos, audio recordings, and advertisements. Once your site is compliant, media specialists—those who work with video, images, or sound on the website—should know all of the previous checklist items in addition to the following items, so new content is also accessible.

7. Closed Captioning Used on Video and Audio

Videos and audio recordings must use a text alternative with equivalent information, usually closed captioning.

8. Audio and Video Do Not Play Automatically

Audio or visual media that plays automatically is disruptive for people using screenreaders. In almost all cases, it should be avoided. This includes videos and audio recordings as well as ads.

9. Audio and Video Players Have Controls

All audio recordings or videos must have mechanisms to start or stop.

10. Visuals Do Not Flash More Than 3 Times a Second

Videos or other visual effects do not flash more than three times a second.

WCAG 2.0 Checklist: For Web Designers and Developers

Web designers and developers are responsible for accessibility in the design and function of the site, including the navigation, templates, plugins, forms, and other functions. These experts have more responsibility when it comes to accessibility. If you don’t have a web expert on staff and you’re not sure what these WCAG 2.0 checklist items mean, test your site’s accessibility and consult with an expert to fix problems.

11. Able to Skip Navigation and Blocks

Users should be able to skip the navigation links at the top of the site, or other blocks that appear on every page. This is most commonly done using a “skip navigation” link, which brings users to an anchor point at the start of the important content on each page. Since municipal sites often have many departments and functions, this is a particularly prominent accessibility problem for state and local websites.

12. Images Used in Navigation Have Alternative Text

If images are used as links for navigation—such as a home icon leading to the home page—alternative text is used to convey what the link is and where it goes.

13. Color is Not Required and Navigation Color Contrast is 3:1 or Better

Key elements like navigation menus, backgrounds, and other essential objects have a color contrast of 3:1 or better. At any area of the site, color is not required to navigate or use the site (for example, a form field turning red as the sole method for indicating an error would not be acceptable).

14. Site Can Zoom Up to 200%

Users can zoom in up to 200% without losing content or functionality.

15. Flexible Orientation

The website is fully functional in either portrait or landscape mode.

16. No Keyboard Traps

A visitor can navigate the site using a keyboard without getting stuck in one area.

17. Forms Are Usable With Keyboard and Screenreader

Form fields are clearly and accurately labeled. All form fields can be filled in and all forms submitted using only a keyboard. If a field is not filled in correctly, the error is clearly displayed and can be read by a screenreader. Error alerts may require ARIA mark-up extensions for accessibility. This is a particularly notable problem for businesses that allow online ordering using forms.

18. Hover or Focus Does Not Disrupt Use

When a user hovers over content to expand it, it can be dismissed, so it does not cover other essential parts of the site and interfere with navigation.

19. Time-Outs Can Be Extended

If there are time-outs, such as logging a user off automatically after a certain time, the time can be extended.

Remember that accessibility is an on-going pursuit. Use the WCAG 2.0 checklist to run through your site for accessibility issues now, and keep this checklist to make sure new content is also accessible. Make sure that everyone who adds content to the site understands the WCAG 2.0 guidelines that applicable to them. To make sure your website maintains accessibility, perform regular checks. With these policies and precautions in place, you can make sure that your website is accessible to all patrons.

By Sam Stemler

Web accessibility helps to make the world wide web usable for everyone. However, many people don’t use the web in a traditional way, and this is often overlooked by web developers, designers and content authors. Many of the most common accessibility issues making sites difficult or impossible to use in a non-traditional way can be easily fixed. Research on programmatic accessibility issues (those commonly detectable by a program) and user-centric accessibility issues (those commonly detected by accessibility expert) shows that these accessibility issues come up the most.

The most common accessibility issues are:

1. Low contrast on text
2. Missing alt text on images
3. Missing link text
4. Ambiguous link text
5. Too many navigation links
6. Empty form labels
7. Unclear form controls
8. Time-Outs can’t be controlled

Top 8 Most Common Accessibility Issues to Avoid and Solve

1. Low Contrast on Text

In WebAIM’s programmatic analysis of the top 1,000,000 homepages, low color contrast on text was the most common accessibility issue, affecting a shocking 85% of pages. The The Web Content Accessibility Guidelines 2.0 (WCAG 2.0), the gold standard for web accessibility, requires contrast of at least 4.5:1 on typical text. This makes it discernible to all users, including those with low vision or color blindness.

Contrast is generally easy to fix. It can be fixed wherever individual problems occur, or it can be fixed site-wide by changing the theme. Accessibility testing tools like a color contrast checker to make sure there is enough contrast between your text and other elements like the highlight or background. Remember that the theme may designate different colors for headings, captions, lists and other types of text.

Accessible Metrics can test your site for this common accessibility issue and many others.
Start your test »

2. Missing Alt Text on Images

This is another very common accessibility issue that is easy to fix. Again detected in WebAIM’s study, missing image alternative text on images (alt text) appeared on 68% of websites. Other, older accessibility studies between 2006 and 2013 cite this problem multiple times as well, indicating that this is a known accessibility issue that has not gone away.

It is worth noting that, though alt text is helpful on any image, there are some exceptions to the requirement. WCAG 2.0 states in section 1.1.1 “If non-text content is pure decoration… it can be ignored by assistive technology.” If the image is purely decorative and does not inform the content or the experience, alt text may not be needed, though it will still be programmatically detected by an accessibility testing tool. Therefore, this issue may be overrepresented in the study.

The easiest way to solve this common accessibility issue is to give all images clear and simple alt text when they are entered into the site. This means that anyone with the ability to enter content on the site, including bloggers, photographers, site administrators and everyone in between, should know the importance of accessibility and how to give alt text to images. Proper training and a clear and apparent accessibility policy available to all staff can help to ensure this.

3. Missing Link Text

Links are one of the main ways we all get around the internet—we use links to enter sites, move through them, and go between them. If it isn’t clear where a link is, where it’s going or how to activate it, moving around the internet and especially around a site becomes much more difficult. Links present a number of common accessibility issues that are often detected by testing programs and experts alike, and missing link text is the most obvious.

Missing link text means that there is no text used to represent a hyperlink. It might be just an image or a button, but someone who cannot visually see the site and uses a screenreader instead cannot interpret it as a link. This can be solved by either hyperlinking applicable text or including alt text for the link.

4. Ambiguous Link Text

You’ve probably seen link text that reads “click here” or “more information.” When, a screenreader reads this information, but nothing else, which does not tell the user what the link is for or where it goes. Instead of hyperlinking the ambiguous text, it is better to use brief, but informative text. For example, the following link would go to WCAG 2.0 Quick Reference. This can be easily overlooked in the site’s design by creating ambiguous navigation links (more on this in the next section), or content creators can create this problem by using ambiguous link text in blogs or other content pieces.

5. Too Many Navigation Links

 

Screenreaders and other assistive device must read out or click through navigation links before getting to the main site content. If you have 50 navigation links at the top of your site, this presents obvious problems. A better way to do this might be using search bars, sub navigations, or a skip navigation link. Skip navigation links provided before menu items allow users to skip the navigation and go directly to an anchor point, usually at the start of the site content. Since they cover so many departments and so much information, this accessibility issue is especially problematic for many local and state websites.

6. Empty Form Labels

Forms are one of the most common website functions users interact with. It can be as simple as a subscribe form requesting a user’s name and email, or a complex as a job application form, with all kinds of form fields. Forms are also one of the most common causes of accessibility issues. A number of different accessibility issues can arise with forms, including those detectable by a program and other issues that programmers and testers frequently discover. Empty form labels are one of the most frequently discovered accessibility issues with forms.

Form labels tell screenreaders and their users what information a form field requires. These labels are not always clear or readable to a screenreader. Some websites use pre-filled text within a form field to show what it is for, and this can present problems to assistive devices. Go through your forms and ensure the form labels and inputs are clear.

7. Unclear Form Controls

Some form controls, such as “next page” or “submit” are clear, but others are more ambiguous. A date selection tool for example, might not be clearly expressed with a screen reader, or easily usable with assistive devices. A number of simple testing strategies will show you whether your form controls are accessible or not.

8. Time-Outs Cannot Be Controlled

For security purposes, many forms will expire after a set time period, especially purchasing forms. However, it often takes longer to use forms with a screenreader or another assistive device. Users must be able to know when the form is about to expire, and they must be able to extend the time limit when needed.

Fixing these top 8 most common accessibility issues means avoiding issues that over 90% of other sites face. While this alone doesn’t guarantee that your site will be accessible—remember that accessibility is about function, not form—it will go a long way towards that goal.

By Sam Stemler

Accessibility requirements for government websites are intended to allow everyone equal access to online resources. This includes web pages, blogs, event pages, videos, PDF tax files, an online form to apply for a dog license and everything in between. These online accessibility standards for government websites are mostly put forth by Title II of the Americans with Disabilities Act (ADA). However, the ADA does not specifically mention websites, which has left some ambiguity as to how to ensure ADA compliance for government websites. In this blog post, we’ll provide helpful resources to make ADA compliance easier, and provide an outline to ensure ADA compliance for your state or local website into the future.

Is My Website ADA Compliant? How Do I Know?

While the ADA itself was designed before websites were common information resources, recent case law has shown that websites fall under the ADA umbrella. The Department of Justice (DOJ) and ADA have offered guidelines and resources to help governments make their websites accessible.

These guidelines, similar to other accessibility guidelines like the WCAG, do not list exactly what governments should or shouldn’t have, but instead outline what the website should do. This gives governments a measurable goal—equal functionality and usability—without using specific criteria that would put limits on how the website looks or what it does.

The ADA and DOJ offer the following documents, among others, to give local and state governments direction as to how and why to make their websites functionally accessible to everyone.

• Accessibility of State and Local Government Websites to People with Disabilities
• ADA Best Practices Tool Kit for State and Local Governments Chapter 5: Website Accessibility Under Title II of the ADA
• ADA Best Practices Tool Kit for State and Local Governments Chapter 5 Addendum: Title II Checklist (Website Accessibility)

Start with an Organized Plan
Download the Website Accessibility Checklist

How Can I Ensure ADA Compliance Now and In the Future?

Websites are not static. They change as technology and users’ needs change. This is why you can usually tell when a website hasn’t been updated in five years, and it’s especially obvious when it hasn’t been updated in ten or twenty. So how can you ensure ADA compliance for your government website, today and years down the line?

If your website is due for an update, it’s a good time to innact accessibility regulations along with a new design. Or, if your website is fairly new, you can adopt ongoing policies to ensure the site stays accessible as new content is added and changes are made. Use the following steps to make a solid plan for ensuring ADA compliance now and into the future.

Step 1: Make an Accessibility Action Plan

If you are redesigning your site, consider accessibility as your build your site. Adherence to website accessibility standards will make your website easily usable for people with disabilities, but it will also improve site functionality for all users. Review the ADA accessibility guidelines and checklist for websites listed above. If you aren’t sure what all of these points mean or entail, don’t worry. The following are a few ways that you can start off with a strong accessible framework.

• Use an accessible template: WordPress works with users who are passionate and well-versed in accessibility to create accessible templates. You can make changes to these templates to suit your site, but this is a good place to start.
• Work with an expert: If you are working with a web design company or an outside consultant, make sure they have experience with accessibility, and a good understanding of what it will take to make your content and functions accessible. Remember, some websites can be accessible very easily, but larger or more complex sites will take more skills.
• Keep it in-house: If your on-staff tech expert is well-versed in web accessibility, they may be able to use outside testing tools to identify problems and fix them by themselves. However, be careful not to overextend your tech staff.

Step 2: Make an Accessibility Policy

Now that your website is accessible under the ADA, you want to keep it that way. As new content is added to your site—new pages, blog posts, pictures, links, forms etc.—you need to maintain accessibility. This is where a solid accessibility policy comes in.

The ideal accessibility policy outlines how to add information to the to the site so it remains accessible. Everyone who adds content should be able to understand this. This policy should also be well-known and up-to-date. Afterall, if your staff cannot find this policy, or don’t know that it exists, it won’t be very helpful.

Keep the following in mind as you craft your accessibility policy. This will help you ensure that the policy is useful today and in years to come.

• Complexity: Some aspects of accessible web design require more technical knowledge than others. As you craft your policy, consider creating tiers of use. For example, everyone adding information to the site should know how to add alt-text, use headings appropriately, and add links with the appropriate text. However, only more advanced users concerned with site navigation or functionality will need to know more complex aspects, like the use of ARIA for accessibility.
• Training: Many people are not aware of what web accessibility is, or how to do it. Make sure that new hires who are working with the website have access to your policy, understand it, and know why it is important.
• Easy to Find: Your accessibility policy should be easy for everyone to access when needed. You might include it in a group of shared staff documents, in a training manual, or in a staff-only section of your website. Make sure everyone knows where to find it.
• Able to Ask Questions: Your staff will probably have some questions about the policy, or they may run into issues they aren’t sure how to solve. Give them a way to resolve these questions. Emphasize that it is better to ask an expert than to guess.

Step 3: Conduct Regular Testing

Inevitably, there will be some accessibility issues that arise as you add new content or make changes. Regular testing for accessibility can help you detect and fix these issues before they get out of hand. It’s a good idea to set aside time on a regular basis to conduct testing and also fix the issues that arise. This might include programmatic testing using testing tools, as well as user testing.

With each of these elements in place, you can ensure that your government website is ADA compliant now and for years to come. This will not only protect you from accessibility civil suits, but it will also ensure that all residents and visitors can enjoy your website equally.

By Erica Statly

ADA stands for the American Disabilities Act, which was published under the Standards for Accessible Design in 1990. The purpose of the law is to protect people with disabilities. While this law was created with physical barriers in mind, as the world continues to evolve, accessibility for disabled people is now a topic for internet users.

Several companies have experienced lawsuits in the past few years due to lack of accessibility. People with disabilities are suing based on the premise that they are unable to use these websites, because they do not accommodate their specific disability. By using this checklist, you can avoid many issues surrounding web accessibility and your website.

The ADA Compliance Website Checklist

The following 26 checklist items were taken from the official Chapter 5 Title II ADA Compliance Checklist.

Accessibility Checklist For Current Web Pages & Content

• Does the top of each page with navigation links have a “skip navigation” link?
• Do all links have a text description that can be read by a screen reader (not just a graphic or “click here”)?
• Do all of the photographs, maps, graphics and other images on the website currently have HTML tags (such as an “alt” tag or a long description tag) with text equivalents of the material being visually conveyed?
• Are all of the documents posted on your website available in HTML or another text-based format (for example, rich text format (RTF) or word processing format), even if you are also providing them in another format, such as Portable Document Format (PDF)?
• If your website has online forms, do HTML tags describe all of the controls (including all text fields, check boxes, drop-down lists, and buttons) that people can use in order to complete and submit the forms?
• If your website has online forms, does the default setting in drop-down lists describe the information being requested instead of displaying a response option (e.g., “your age” instead of “18 – 21”)?
• If a web page has data charts or tables, is HTML used to associate all data cells with column and row identifiers?
• Do all video files on your website have audio descriptions of what is being displayed to provide access to visually convey information for people who are blind or have low vision?
• Do all video files on your website have written captions of spoken communication synchronized with the action to provide access to people who are deaf or hard of hearing?
• Do all audio files on your website have written captions of spoken communication synchronized with the action to provide access to people who are deaf or hard of hearing?
• Have all webpages been designed so they can be viewed using visitors’ web browser and operating system settings for color and font?

Check these items off your list

Download the Website Accessibility Checklist

Accessibility Checklist for Policies & Procedures

• Do you have a written policy on website accessibility?
• Is the website accessibility policy posted on your website in a place where it can be easily located?
• Have procedures been developed to ensure that content is not added to your website until it has been made accessible?
• Does the website manager check the HTML of all new webpages to confirm accessibility before the pages are posted?
• When documents are added to your website in PDF format, are text-based versions of the documents (e.g., HTML, RTF, or word processing format) added at the same time as the PDF versions?
• Have in-house staff and contractors received information about the website accessibility policy and procedures to ensure website accessibility?
• Have in-house and contractor staff received appropriate training on how to ensure the accessibility of your website?
• Have in-house and contractor staff who create web content or post it on your website received copies of the Department of Justice’s technical assistance document “Accessibility of State and Local Government Websites to People with Disabilities”?
• If your website contains inaccessible content, is a specific written plan including timeframes in place now to make all of your existing web content accessible?
• Have you posted on your website a plan to improve website accessibility and invited suggestions for improvements?
• Does your website home page include easily locatable information, including a telephone number and email address, for use in reporting website accessibility problems and requesting accessible services and information?
• Do you have procedures in place to assure a quick response to website visitors with disabilities who are having difficulty accessing information or services available via the website?
• Have you asked disability groups representing people with a wide variety of disabilities to provide feedback on the accessibility of your website?
• Have you tested your website using one of the products available on the Internet to test website accessibility?
• Are alternative ways of accessing web-based information, programs, activities, and services available for people with disabilities who cannot use computers?

Take the time to ensure your website fully accessible to internet publics by using our checklist. Use Accessible Metrics to automatically scan your website monthly for ADA compliance.

By Sam Stemler on May 21, 2019

Local and state government resources are intended to serve the public, and this includes websites as well as buildings. Residents now look for forms and information online more often, making website accessibility even more important. States, cities, counties, townships and other municipalities have a number of government website accessibility standards to adhere to. Here is an overview of government website accessibility standards, and what these mean for local and state government websites.

Government Website Accessibility Standards: Local and State

Government Website Accessibility Standards: ADA and Section 508

Government website accessibility standards for local and state are generally provided by Title II of the Americans with Disabilities Act (ADA). In cases where federal funding is provided, the site should also follow Section 508 of the Rehabilitation Act. Fortunately, both of these rules require many of the same things, and are built to enforce the same general requirement; equal usability and functionality of public resources for people with disabilities.

Start with an Organized Plan
Download the Website Accessibility Checklist

Additional Documents and Best Practices

While the ADA does not specifically mention websites, as the legislation was built before online resources were widely used, many municipalities have been subject to lawsuits under ADA Title II for inaccessible websites. In these cases, cities, townships, counties and others have been fined and ordered to make their websites accessible.

These cases can be avoided by taking preemptive steps to adhere to government website accessibility standards. ADA.gov outlines best practices for state and local governments, while the Supplemental Advanced Notice of Proposed Rulemaking (SANPRM) from the Department of Justice (DOJ) provides more information on what accessibility means, and where these government website accessibility standards come from, which we will outline below.

Developing a Web Accessibility Policy and Plan

To begin and maintain web accessibility, ADA.gov and the DOJ recommend building a web accessibility policy and plan to start. This should include; a process for implementation, what will be required to make the website accessible, and the expected costs. If you are redesigning or newly creating your website, you might start with a plan to use an accessible platform or template. These policies should be made public, so residents can weigh in on the process and improvements.

Developing Web Accessibility Guidelines

Web accessibility is an ongoing requirement. As web pages, videos, pictures, forms, and other content is added to the site, these things can become inaccessible without due diligence. Have guidelines in place to help everyone working with the site make sure content is accessible. Make sure these guidelines are well-understood, and give employees a contact person or resources they can use to answer questions or solve problems as they arise.

Implementing WCAG 2.0 AA

In the SANPRM, the DOJ explains, “WCAG 2.0 has become the internationally recognized benchmark for Web accessibility….Thus, the Department is considering proposing that public entities comply with WCAG 2.0 Level AA.” While this is not yet the official government website accessibility standard, it is the standard used worldwide and it has the highest likelihood of being written into law in the future. WCAG 2.0 level AA also provides “four principles that provide the foundation for Web accessibility. Under these four principles, there are 12 guidelines setting forth basic goals to ensure accessibility of Web sites. For each guideline, testable success criteria” are also provided. This makes WCAG 2.0 AA an understandable and testable standard for web accessibility.

The four principles, and a good starting point for your government website accessibility policies, are as follows:

• Perceivable: “Information and user interface components must be presentable to users in ways they can perceive.” This includes features like captions and audio descriptions for media, acceptable color contrast, resizeable text, and elements that can be interpreted by a screen reader or similar device.
• Operable: “User interface components and navigation must be operable.” This includes elements required to navigate the site, such as menus, headings, labels, links, and the ability to move with a keyboard.
• Understandable: “Information and the operation of user interface must be understandable.” This includes the predictable and intuitive use of the site, such as with navigation elements, identifiers, and error suggestions.
• Robust: “Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.” This includes the compatibility with assistive technologies and how these technologies interact with the site.

Conduct Testing

The best way to determine whether or not your website meets these standards is to actually test it. If your website does not work well with assistive technologies, it probably doesn’t meet the government website accessibility requirements. Remember that the goal is based on function—making your site useful to all constituents—and not adherence to specific rules.

With these government accessibility standards in mind, as well as guidelines for how to meet them, your municipality can avoid costly lawsuits, and make your online resources equally available for all residents.

By Sam Stemler on May 7, 2019

Testing for the accessibility of your website does not have to be complicated. With the right accessibility testing strategy, you can find obstacles in your site and remove them. This will help you make your site usable for all patrons, ensure your site is compliant with rules and regulations, and help you avoid accessibility lawsuits. In this blog post, we’ll explain how to test the accessibility of a website in 5 steps.

Step 1: Test for Links, Alt-Text and Markup
Step 2: Test for Navigability and Operation Yourself
Step 3: Expert Testing for Function and Value
Step 4: User Testing for Confirmation
Step 5: Make a list of changes

How to Test the Accessibility of Your Website

Step 1: Test for Links, Alt-Text and Markup

There are a variety of tools available that can automatically test for a number of different accessibility obstacles like problems with links, alt-text, and HTML markup. When it comes to learning how to test the accessibility of your website, this is a great first step. These accessibility testing tools will show you clear errors in your site that create challenges for people with disabilities. Some of these tools are available for free online, while others are paid programs or subscriptions.

Remember that automatic tools can only take you so far. These tools scan the code and construction of your site to find known accessibility obstacles, but they can’t use, understand and interact with your site as a human would, so they can’t detect obstacles posed by semantic meaning, images, or site operation. Programs and tools can help you check for the following issues one at a time. Accessible Metrics can test a page of your site or your entire website for all of these features and others.

• Color contrast
• Alt-text
• Dead links and link text
• Tab-index
• Iframes and embedded media
• HTML mark-up

Remember, as you use these tools, write down or otherwise record the issues you encounter, so you can develop a strategy for fixing them in the last step.

Keep your notes organized
Download the Website Accessibility Checklist

Step 2: Test for Navigability and Operation Yourself

You don’t have to be a web designer, programmer, or an accessibility expert to test whether or not users can navigate and operate your site with some assistive technologies. You can see how to test the accessibility of your website on your own by making a few small changes to the way you use your site and your computer. Try the following tests yourself and see how your site works. Once again, write down or record obstacles you find.

• Remove Style Sheets: Web developer plugins, extensions, and add-ons for Chrome, Firefox and other browsers allow you to turn off styles. This means you’ll see the site content only, similar to how a screenreader and other assistive tools would “see” the site. If your site is difficult or impossible to use without stylesheets, it probably isn’t accessible.
• Use Keyboard Only: A keyboard works with a site similarly to many assistive devices, so navigating your site with a keyboard instead of a mouse will show you whether it is navigable with these tools.
• Remove Images: Selections in the tools or settings menus can stop your browser from loading images. If you can’t understand or navigate your site without them, visually impaired users won’t be able to either.
• Use Screen Magnification and High Contrast: Many visually impaired users magnify the screen and/or turn on high contrast to use websites. You can do this yourself by zooming in, adjusting settings or adding your browser’s accessibility extensions.

Step 3: Expert Testing for Function and Value

The previous steps will give you basic knowledge as far as how to test your website for accessibility. However, unless you are familiar with assistive technologies, website construction, or both, you might miss accessibility issues with the more detailed or elaborate functions of your site. An expert can manually test your site and look for issues in your site’s unique construction and code, in order to find obstacles that impact what your site does or value it provides.

The following are functions and features a designer or developer with experience in accessibility might look at:

• Forum Posting and Moderation: If users can post to and moderate forums as a part of your website, an expert can help to make sure everyone has equal access to it.
• Form Filling and Filing: A number of accessibility issues can arise if forms are not programmed correctly. If filling out or filing forms is an important part of your site, this should be equally functional and usable for everyone.
• PDFs and Other Files: Screenreaders and other assistive devices interpret PDFs and other files differently from webpages. An expert can help you make sure these are formatted properly.
• Chatbots and Popups: In your previous testing, you may have noticed if chatbots, popups, or other features made the site difficult to navigate. An expert can work with these further, and pinpoint specific issues.
• Specific Programs: There are many other functions or programs your site might provide that are specific to your business or industry. Work with an expert who is experienced with accessibility and the program’s code to test it.

Step 4: User Testing for Confirmation

How can you test the accessibility of your website without asking real users who use assistive technologies? This is an important step in seeing how your site really works when it is used in a non-traditional way. You will get the most value out of this step if your users can test all parts of your site. This might mean fixing some obvious or particularly problematic accessibility issues you discovered earlier.

There are several ways to find testers who use assistive technologies. You might work with local organizations or advocacy groups, put out an ad and organize a testing group or session, or arrange user testing with a private company. The following are common disabilities a user might have which would require assistive devices or other extensions.

• Visual: This might include blindness, partial blindness, or color blindness.
• Dexterity: Impairment of fine motor skills like tremors, inability to move the fingers, or a loss of coordination can create dexterity challenges.
• Movement: Paralysis or other loss of movement to the hands or arms limits the use of a keyboard and mouse.

Step 5: Make a List of Changes

Now that you know how to test the accessibility of a website, it’s time to put your insights into action. You may have already fixed some of the accessibility issues you encountered at earlier steps, and there are most likely others you recorded that you haven’t fixed or aren’t sure how.

The best way to organize these changes is by cost and benefit. Ideally, start with changes that are easy to implement and benefit a large number of people. For example, adding alt-text to important images and links benefits everyone who uses a screenreader, and you can do this yourself. A more difficult, but manageable change might be changing your navigation menu to be operable with a keyboard or similar device. A high-cost change might be hiring a programmer or web developer to fix issues with a special function.

Take on these changes piece by piece. When you have a budget and a plan, making your site accessible will become a much more manageable project.

You now have a thorough method for how to test the accessibility of your site. Remember as you make changes to your site to design for accessibility, and test continually so you can catch issues before they become problems.

by Sam Stemler on Jan 8, 2019

Web accessibility means more than checking boxes to adhere to a law or guidelines. Functional web accessibility is about the user experience (UX) and ensuring that all web visitors can access and use your site. While automated web accessibility testing programs are useful for finding problems fast, fixing these issues often requires the help of a web accessibility specialist. Whether you are hiring a full-time staff person or working with a consultant, it’s important to pick the expert who knows how to address your problems and fix them. Here’s a breakdown of the education, skills, knowledge and experience you should look for when hiring a web accessibility specialist.

Knowledge, Skills and Experience to Look For in a Web Accessibility Specialist

What is an web accessibility specialist?

What you should look for when hiring a web accessibility specialist will depend on what you are testing and fixing. If you are testing your website for accessibility, you’ll need a web accessibility specialist who is experienced with the elements your website uses to function, as well as the accessibility issues that can arise within these elements. You might also be conducting accessibility testing for an app or software you developed, which will require some additional skills.

To decide what to look for when hiring a web accessibility specialist, make a list of the elements you are using and testing. This might include any of the following:

• Elements controlling the appearance and functionality of your website, such as CSS and JavaScript.  
• The foundational elements of your website or the functionality of your program, such as PHP, Python, Ruby, Ruby on Rails, Java or MySQL.
• The Content Management System (CMS) through which you input and display content, like WordPress, Drupal, or DNN.

There are many other technologies you may use. Hiring a web accessibility specialist who is familiar with these will simplify accessibility dramatically.  

Work with accessibility experts who are also developers and designers. Ask about manual accessibility testing ›

Education

Hiring the right web accessibility specialist often starts with education. A formal education in computer programming, information systems, or web design generally provides the foundational knowledge needed to build and understand websites and programs, though additional experience and knowledge is needed to design for accessibility specifically. Graduates of this field may or may not take courses or lessons addressing web accessibility, so their experience with accessibility may vary.   

Web Development Skills and Experience

Specific skills and experience are two of the most important things to look for when hiring a web accessibility specialist. When deciding what skills or experience you’re seeking in an applicant or consultant, it’s helpful to refer back to your list of programs, programming languages, or systems your website or software depends on. It’s also helpful to use the results from your automated testing. If your accessibility issues are mostly content-based, such as missing alt text, disorganized headings, or unclear links, then your accessibility specialist should be skilled with your CMS, as well as SEO. If your accessibility issues are primarily UX problems, then web design and functionality will be more important.

Keep in mind that web development and design skills are important, but your web accessibility specialist must also be able to apply these to accessibility. This means they should also have experience with assistive technologies that a person with a disability might use to access your site or program, as well as automated testing tools used to uncover accessibility roadblocks.

Here are some of the skills and experience your web accessibility specialist may need:

• Web design using CSS, HTML, and JavaScript
• Web development using XSL, XSLT, JavaScript and JQuery
• Content management using WordPress, Drupal, DNN or another CMS
• Web application development using Angular JS, Ruby on Rails, Ember.js or another framework.
• Fluency with English or the primary written language used.
• Experience with JAWS or NVDA
• Experience with keyboard testing
• Experience with automated testing tools and reports  

Web Accessibility Knowledge

In addition to hard skills and formal education, certain knowledge will also be an important part of what to look for when hiring a web accessibility specialist. Most importantly, the web accessibility expert you hire should have in-depth knowledge of accessibility laws, guidelines, and best practices. Much of this information is freely available through the World Wide Web Consortium (W3C) and other resources, though the extent to which the specialist can apply this knowledge will also be important. This knowledge makes the difference between a regular web developer or designer and one who specializes in accessibility.

Here’s some of the knowledge your accessibility specialist should have:

• A good understanding of WCAG 2.0 and what this means for the UX
• Knowledge of SEO best practices
• A good understanding of laws surrounding web accessibility, including ADA, Section 508, state- or industry-specific guidelines, or web accessibility case law as needed.
• Knowledge of and ability to use WAI-ARIA where necessary
• Understanding of desktop, mobile and responsive web design

What to look for when hiring a web accessibility specialist depends a great deal on what you are working with, but all web accessibility specialists should have some skills and knowledge in common. Most notably, they should know, and be able to explain the importance of WCAG, as well as why web accessibility matters. They should also have experience with assistive devices, whether for testing purpose or first-hand knowledge. Finally, your candidate should be able to demonstrate their success with web accessibility, and their previous projects should be similar to yours.

Maintaining web accessibility is an ongoing process, though there are many different types of web accessibility specialists that can help. You might work with a consultant regularly to ensure your website or program is compliant, you might hire a full-time or part-time employee, or you might work with a third-party to conduct regular manual testing. Whoever you choose, make sure you have a good understanding of their knowledge, skills, and experience, as well as what you expect from them. 

By Sam Stemler on Dec 11, 2018

The World Usability Day Event at Michigan State University on November 8th, 2018 gave Mid-Michigan web developers, academic professionals, students, lawmakers and many more a closer look at the importance and practical application of web accessibility. The event included an array of accessibility professionals illustrating the need for an accessible web, and helping to solve the challenges that developers, web designers, bloggers and users face. They addressed planning for web design and accessibility, interdepartmental teamwork, and, ultimately, why web accessibility matters to all users.

Why Web Accessibility Matters: From W3C

Shawn Henry, computer science researcher with MIT and Outreach Coordinator with the World Wide Web Consortium (W3C) provided specific insight at World Usability Day into how the governing standards for accessibility, WCAG, are developed, and explained the recent updates in WCAG 2.1.

Henry described not only the technical implications of the changes, but also how these changes impact the user experience (UX) of all users, including those with disabilities and those without. Understanding the UX behind the web—not necessarily understanding the exact rules or wording of WCAG—is the first step, she said, towards understanding why accessibility matters.  

Essential to Some, Useful for All

While the literature on WCAG provides a helpful technical roadmap for web accessibility, Henry better explained the real-world implications of accessibility, not only for users with disabilities, but for all users in all situations. This is an important attribute of WCAG best explained as “essential to some, useful for all” and helps to illustrate why web accessibility matters for all users.   

The 17 new success criteria in WCAG 2.1 began with 60 new proposals, which were based on obstacles faced by people who use the web in many different ways. These new criteria provide dramatic functional benefits for many people with disabilities. They’re also beneficial for people who use the web in the traditional way, but might sometimes use it in non-traditional circumstances, such as in a difficult environment, using a new device, or working with a temporary limitation. Web developers who are conscious of accessibility can also reap the benefits of new trends and technology faster than those who are not. The UX which inspired many of the changes in WCAG 2.1, and several examples provided by Henry, help to explain this in more detail.

Traditional Use, Non-Traditional Circumstances  

The new WCAG 2.5.4 concerns motion actuation. Essentially, accessible websites which follow this guideline do not require motion to function, and any motion activation can be turned off if needed. To explain the UX behind this guideline, Henry asked developers to consider two potential users who might benefit: a user who struggles with hand tremors and therefore might accidentally activate a function without meaning to, or a user on a bumpy bus, who might do the same. Sites that incorporate WCAG 2.5.4 would be usable for both people. If your website or application serves elderly users, or users who are often on-the-go, it will be obvious why web accessibility matters in this case.  

Removing Barriers and Inconveniences

Often, the same accessibility guidelines that remove barriers for people with disabilities also remove inconveniences for other users. One example of this is WCAG 2.5.5: Target Size. This success criteria specifies that control elements, such as buttons, navigation menus and some links, should be at least 44 by 44 pixels. This makes the website easier to use for people using alternative control devices, or those who struggle with fine motor control.

This criterion also removes an inconvenience which all users are likely familiar; trying to tap a tiny button while browsing on a mobile device. When controls are large and prominent, the site is more usable for everyone. Though this criteria is rated AAA and most rules and standards only require AA compliance, it’s worthy of consideration even if it doesn’t present a legal risk.  

Adapting to New Technology First

In some cases, functions that are essential for users with some disabilities eventually become desirable functions for all users as new technology develops. One example of this is voice commands and voice search. For users who cannot use a keyboard, the use of voice commands to navigate a site are very helpful, even imperative. This is often completed through ARIA labels on buttons and links. WCAG 2.5.3: Label in Name requires the accessible label to be in the name of the element it describes.

To illustrate this from a UX standpoint, Henry described a the case of a real user who tried to submit a website form using voice commands. On screen, the button was “send,” however the label was “submit,” which the user could not know since they didn’t use a screen reader.

As the use of home assistants and other Internet of Things (IoT) devices have increased, voice searches have also increased dramatically, and will continue to do so. Many IoT devices process web pages similarly to a screen reader, and read them out to users instead of showing them. Web developers who properly label key elements of their site will already be ahead of this trend, allowing users to search their site, submit information, and perform other tasks through voice commands alone. This may be particularly important for websites or applications targeting multitaskers, such as recipe sites for parents in the kitchen, podcast sites for drivers, or fitness applications for runners. As more users rely on web searches and services while conducting other activities, voice commands will become more important.

Building a Better Web and Better UX

World Usability Day helped to bring web accessibility out of guidelines and rulebooks, and into the real world. As more web experts with interdisciplinary knowledge understand why web accessibility matters and the real world implications, we’ll continue to see a better UX across the World Wide Web.

 

By Sam Stemler on Nov 13, 2018

Webpages and applications are designed to solve all different tasks. They need to give web developers the creativity and ability to solve all different types of problems, while still being intuitive and accessible for web users. This becomes more of a challenge, however, if you use the web differently than others. If, for example, you use a screen reader instead of a visual display, the construction behind the page becomes much more important than the appearance. This is where Accessible Rich Internet Applications (ARIA) come in. In this blog post, we’ll explain the basics of ARIA for web accessibility.

How to Use ARIA for Web Accessibility

WAI-ARIA Basics

WAI-ARIA was developed by the Web Accessibility Initiative (WAI), part of the World Wide Web Consortium (W3C). WAI-ARIA, or ARIA for short, is a set of markup extensions which are meant to provide additional description or meaning to elements within the site or application. ARIA attributes are used in websites and webpages, blogs, games, social media, and much more. For the purpose of this blog post, we’ll explain how ARIA attributes are used to improve accessibility for websites.

Not all websites use or need to use ARIA attributes to be accessible. In fact, ARIA attributes are intended to be used only when a part or function of a site is difficult to use or unclear with a screen reader or assistive technology. Many of the most common elements you’ll see in modern websites today are already accessible, and don’t need additional ARIA attributes. However, if you have tested your site and it isn’t accessible, ARIA may offer solutions to fix it.

Since the web is so vast and there are so many different ways that information and content may be displayed, ARIA must be versatile, with the ability to solve many different accessibility issues. To help organize ARIA solutions, they are mainly divided into three subsections: roles, states, and properties. We’ll describe each one, and what it does, in more detail below. For a more in-depth look into ARIA functions and organization, see the WAI-ARIA 1.1 document.

Organize your web accessibility step by step. Download the Ultimate Web Accessibility Checklist >

ARIA Roles

ARIA roles are described using role= in your website code. For example, the navigation menu of your site might use role="navigation", or a search bar might use role="search". On the outside, to users looking at your site, nothing changes by using an ARIA role markup extension, and all elements function the same way. To users with assistive technology, however, roles can provide extra meaning and usability to an important area of the site. Roles allow a screen reader to easily convey what the element is supposed to do, what it means, and allow the user to more easily interact with it when needed. These are not the only types of ARIA roles used for website accessibility, but they are some of the most common.

• Landmark roles: these help users navigate websites more easily when using screen readers and other assistive technology (AT). These include role="navigation", which is used to highlight groups of links used to click around the site, or role="form" for showing where a user might input some information, like a contact form.
• Widget roles: these provide more clarity about what a part of the website is supposed to do, and make it easier to interact with. One widget role is role="button", which shows what an element is and when it should be clicked. Another is role="progressbar", which shows that an element is displaying the progress of a task.
• Live region roles: these show that an element is dynamic and changes based on certain criteria. For example, role="alert" triggers a message, like error messages. Another live region role is role="timer" which might be used to show that a user has a limited time before being automatically logged out, or that a deal is ending soon.

ARIA Properties

While roles describe what an element does or what function it is meant to perform, ARIA properties describe more about what the element is. ARIA properties and roles are often used together, as a role might describe the function of an element and a property might describe one part of the element. Most of the time, though not always, ARIA properties do not change as a user clicks or interacts with a site, while ARIA states do. Since they are used in similar ways, ARIA states and properties are often collectively called ARIA attributes. Here are some common types of ARIA properties you might see on a website:

• Widget properties: these generally describe one part of a widget and give it additional meaning, so the widget might be more useful. For example aria-required="true" used with an input element would indicate that the element must be filled in for the next step to continue.
• Live region properties: these describe how live regions in a site update and how a screen reader interacts with them. For example, aria-live="polite" would inform the user that the live region has changed, but would not interrupt a task, while aria-live="assertive" would be used only for live updates that are essential to the user experience, as the screen reader would interrupt the task to read these.
• Relationship properties: these describe when two or more elements share an important relationship, such as labels, controls, or descriptions, among others. For example, aria-labelledby="first name" used with a form input would clearly show a screen reader and a user what the input is.

ARIA States

ARIA states are very similar to properties. The key difference is that ARIA states indicate change. ARIA states are most useful with live regions, a part of a site that regularly updates, or with alerts, which notify users of important information. The following are common types of ARIA states used for web accessibility:

• Widget states: Widget states are very similar to widget properties, except they can be changed with a user’s action. For example, the ARIA state aria-expanded="true" would show that a box, tree, table, or another element is expandable, and the current state is expanded.
• Live region states: Live region states are used in conjunction with live region properties to show users what these parts of websites are doing. The state aria-busy="true" shows that an area is in the process of updating.

ARIA are meant to make your site more accessible, and help you overcome accessibility obstacles within your site. Some ARIA attributes and roles are easy to implement, while others will require some more coding knowledge. Remember that ARIA is meant to help your web accessibility, and you may not need it. If you have an accessibility issue that is restricting important content or functionality from your site, a web developer may be the best option to help you find the right solution with ARIA tags.