Getting Started with Web Accessibility

Download the Getting Started with Web Accessibility Guide

This guide is for beginners interested in making their websites more accessible to people with disabilities. The process does not need to be difficult, especially when you incorporate accessibility into your existing practices. Whether you are creating/managing a website on behalf of a government agency, small business, cultural institution, or an artist, this guide will have something for you.

Basic Concepts

Before we start talking tech, let’s look at who we are talking about, what they use, what’s required, and what access looks like.

Who are People with Disabilities?

The World Health Organization estimates that 15 to 20 percent of the world’s population identifies as having a disability. In New York City, there are nearly a million people that identify as disabled—around 11%. It is our responsibility to make sure we can connect with the disability community with our websites, email communications, electronic documents, videos, and social media posts. In the digital space, when we say users with disabilities, we are referring to disabilities that affect the eyes, ears, hands, and brain.

Examples include:

Eyes: people who are blind or have low vision
Ears: people who are deaf or hard of hearing
Hands: people with physical disabilities that are unable to use a mouse or keyboard
Brain: people with learning, cognitive, intellectual, or developmental disabilities

What are Assistive Technologies?

Some people with disabilities use assistive technologies. Assistive Technology (AT) is any piece of equipment, product, or system that is used to maintain or improve the functional capacities of people with disabilities. Common examples include wheelchairs, hearing aids, crutches, and even glasses and contact lenses. Additionally, AT can be software or hardware that a person uses to access their technology.

Some assistive technologies used with websites include:

Blindness: People who are blind often use screen readers, which are a type of software that reads the contents of the screen aloud.
Low Vision: People with low vision often use screen magnifiers, to enlarge the contents of the screen. They might also use inverted colors.
Hands Free: People with physical disabilities that limit their ability to use a mouse or keyboard often use alternative devices that allow them to control computers and smart devices with their voice, a switch control, a head wand, by moving their eyes, or even with their breath. Learn more about hands free technologies.

What are the Laws?

There are both City and Federal laws that apply to websites in New York City.

Local Law 26 of 2016

Signed on March 14, 2016, Local Law 26 requires New York City to adopt a website accessibility standard and work with city agencies to make all websites managed by, or on behalf of, the City of New York compliant with this standard. The current standard that the City of New York is conforming with is Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA.

The Americans with Disabilities Act

Signed in 1990 by President George H. W. Bush, the Americans with Disabilities Act (ADA) created a legal definition of disability as well as protections for people with disabilities from discrimination in the public and private sectors. The ADA is often used in website accessibility lawsuits. While the ADA does not mention standards specifically, WCAG 2.2 Level AA criteria are often used as the standard to measure against for ADA lawsuits. The Department of Justice has also released a Final Rule on Website Accessibility for State and Local Governments that mandates WCAG 2.1 Level AA, with five limited exceptions, as the technical standard used to determine compliance with the ADA.

Section 508

Section 508 of the Rehabilitation Act of 1973 requires access to Information and Communication Technology (ICT) provided by the Federal government or any entity that is receiving Federal funding. For more guidance, refer to section508.gov.

What is the WCAG?

The Web Content Accessibility Guidelines lay out four principles of accessibility. These principles frame the success criteria, which have three levels (A, AA, and AAA), used to determine if a website is accessible.

These four principles ensure web content is:

Perceivable
Will people with disabilities be able to perceive the content on your website? For example, if there are images, do they have descriptions through alternative text for blind visitors? Do videos have captions for deaf visitors?
Operable
Will people with disabilities be able to operate your website? For example, all items that can be clicked on using a mouse should also be accessible to keyboard-only users.
Understandable
Will people with disabilities be able to understand what they are doing on your website? For example, do forms have accessibility labels and proper instructions? Do required fields have text alternatives?
Robust
Is your website compatible with current operating systems, browsers, and assistive technologies? Websites that are built using standard HTML 5 make implementing accessibility an easier process.

Read more about each WCAG criterion, including explanations and examples, by referring to the Understanding WCAG Success Criterion link next to each of the WCAG 2.2 Success Criteria.

Steps to Achieve Access

You want your website or portal to be ‘born accessible.’ This happens when accessibility is considered and built into the project at each phase of the process. When accessibility is left to the end, addressing the issues found becomes more difficult, time consuming, and expensive. In three steps you can be on your way to an accessible website.

Step 1: Platform & Template Accessibility

The first step is to determine if the platform and template your website uses supports accessibility. To do this, find out if the website was built using a website builder such as SquareSpace or Wix, a content management system like Drupal or WordPress, or another system. You can then research that platform’s accessibility support and features.

Website Builders

If your website uses a website builder, look up the platform’s accessibility by searching the internet for the name of the platform and ‘accessibility’. If no results are found, the platform most likely does not support accessibility. In that case, transitioning to a more accessible platform is advised.

Two things to consider while evaluating the builder are the availability of accessible templates or themes and whether there are tips on how to effectively use the accessibility features that the platform supports. Be sure that your website uses an accessible template/theme and follows all the guidance for using the built-in accessibility features.

Accessibility guidance for some popular website building platforms:

Content Management Systems (CMS)

If your website is built using a content management system, such as WordPress, be sure to research the accessibility of the CMS as well as the template or theme that is used for your website. Much like website builders, CMSs support accessibility features to differing degrees. Find out what they are and be sure to incorporate them into your process when editing or adding new content.

Popular CMS accessibility:

Accessible Design Systems and Frameworks

Perhaps you are looking to transition to a new website that supports accessibility. Below are some accessibility-focused design systems and frameworks that you can use.

Use of Industry Best Practices

It is highly recommended that your website designers, content creators, and developers follow established HTML and CSS best practices for common elements of a website, such as images, headings, links, form elements, and buttons. You should make sure that your design system, template, or website building platform supports as many of these as possible. The NYC Digital Design System has additional guidance and resources.

Step 2: Design and Development

There are two aspects to creating an accessible online experience—compliance and usability. It is important to understand that making your site compliant does not automatically mean it is easily usable. So, while designing and developing your site to comply with WCAG 2.2 AA, it is critical that your design and development efforts include creating a user experience that is easily usable for both keyboard and mouse users.

There are three areas of best practice to consider:

Design
Writing
Development

As you map out your site and finalize your design and code, keep in mind that providing choice—multiple ways to access information or accomplish a task—will always increase your website’s usability and accessibility.

Design

When designing the layout and user experience, it is important to consider the varied ways people access and consume content. Multiple modalities for information delivery will allow those with sensory disabilities access to the information on your site. For example, you would want to avoid audio-only alerts, the use of color alone to convey meaning, and images of text. Audio and video content should have alternatives like captions, audio description, and/or transcripts.

The color palette used is important to more than just brand identity, it can determine whether all your users can consume the content. The contrast of text with its background needs to be sufficient—a minimum of 4.5:1, though 7:1 or better is preferred. When designing form elements, users need to be able to easily know where the information requested should be entered and what information needs to go where.

Content layout can impact a site’s ease of use, both positively and negatively. Use clear headings and space to organize the content into logical chunks. Any elements you want the user to interact with need to be clearly identifiable, with their purpose obvious. Busy and crowded layouts with ambiguous interactive elements will only confuse and frustrate your user.

A mobile-first design will not only offer cross-platform usability but also gives your users flexibility in the way they access your site. Designing for different viewport sizes means paying attention to how the content will be laid out on both small and large screens. Use relative sizing for text, images, and containers. Viewport size-agnostic menu and navigation systems should be clear and consistent.

Writing

The way your content is written will determine whether your users are successful in getting the information they need or accessing your programs and services. Use the concepts of plain language to make your content clear and concise. Plain language also makes page translation easier and more accurate. You can find more Plain Language Guidance on the NYC Digital Design System website.

The structure of your pages should make it easy to find information and know where the user is within the site. Your page titles (what shows up in the browser’s tab) need to be unique, concise, and descriptive of what is on that page. Use meaningful headings to provide structure and help users quickly find what they need. Let visitors know exactly where a link will take them or what a button will do with link and button text that is unique and descriptive. Your users need to know what to expect and what to do when filling out forms, so, provide clear, concise instructions and error messaging.

Remember to provide information in multiple modalities. Images need descriptive alt text. This is best done by the person choosing the image. Content creators should include the alt text that provides the information or function of an image for insertion into the image’s alt attribute. Remember that videos need captions and audio descriptions. Any audio-only content, like podcasts, must include a transcript.

Development

As your engineers transform the website’s design into code, their work can provide access technology users with the ability to understand and navigate the site. Implement a clear semantic structure by using region and heading elements appropriately. While headings carry a certain style, their primary function is to provide semantic meaning. An outline-like heading structure can establish a clear overall understanding of the content of a page.

As developers create the site’s structure, they should keep these things in mind. The site’s code needs to allow the content to be responsive to a user’s device and browser choice and preference settings. A page’s code should mirror the content’s logical reading order. The overall language of the page and all other-language content need to be identified with the appropriate lang attribute, which should also update upon translation.

Not every user accesses the web using a mouse or finger. All interactable elements need to be usable with both a keyboard and mouse. Custom widgets and components need to provide information about meaning and state. This can be done using WAI-ARIA attributes. All images must have an alt attribute. Images that convey additional meaning will have descriptive text (alt=”A dog sniffing a package.”) while those that are purely decorative will be empty (alt=””).

To make forms accessible and easy to use, keep the following in mind. Form input elements need to be labeled and that label needs to be associated with its input (use <label for=”[input ID]”>). Groups of related inputs, like checkboxes or radio buttons, must be labeled, with the same association (use <fieldset> and <legend>). Help users avoid mistakes by providing adequate help text letting them know what is expected for a given input (like a particular format). Also help them identify and fix mistakes with error messaging that indicates what the error is and how to fix it. It is recommended that CAPTCHAs be avoided. Instead use more modern methods for determining human input.

Dive Deeper

Check out the W3C’s Tips for Getting Started for additional information and resources.

Step 3: Accessibility Testing

Testing the accessibility of your templates, pages, and components is crucial. These accessibility checks, as appropriate, need to happen at each step in the Software Development Life Cycle. There are automated and manual methods for testing. Automated testing is quick but can be inaccurate and does not cover all the WCAG criteria nor captures all issues found during manual testing—only around 30%. Manual testing is more work but is required to get an accurate assessment of the accessibility of your website.

Automated Testing Tools

There are many free and paid automated testing tools. As mentioned before, it is important to keep in mind that automated testing tools miss a lot and can make mistakes. Below is information to help you get the most out of them.

Free Automated Testing Tools

The following are examples of free automated testing tools. Note that they only allow page-by-page testing. There are site crawlers, but they come with a cost. Nearly all automated testing frameworks use the same base aXe Core Accessibility Engine developed by Deque Systems.

Available as a browser extension:

Accessibility Insights (Microsoft)
aXe (Deque Systems)

Accessibility Insights is especially useful because it walks you through some manual testing methods that help to capture more issues.

How to Use Accessibility Insights

After installing the browser extension (available for Chrome and Edge), navigate to the page you would like to test and then open the Accessibility Insights extension menu. There are multiple options for testing. FastPass is mostly automated and takes just a few minutes. Quick Assess is a guided review that takes about 30 minutes. The Assessment tool will walk you through a complete assessment of the page and can take a couple of hours.

Start with choosing FastPass. A new browser window will open and display the results from the automated test. Clicking on any issue will highlight it in the original window and provide context to help developers fix the issue. You can choose ‘Export Results’ to download and share the issue details.

You can then continue with some basic manual tests. Start by choosing ‘Tab Stops’ from the left-side menu. A new screen appears with instructions on how to proceed. While this looks complicated, it is simple.

Tab Stop Testing:

Activate Visual Helper
Switch back to the page being tested and press the Tab key to step through each interactable item. Each item will automatically be numbered by FastPass.
Return to the FastPass window, you will notice some issues will have been automatically detected.
Answer the five Pass/Fail questions to complete the Tab Stop testing.

The ‘Needs Review’ tab will give additional suggestions and guidance on more manual testing techniques. For more information on the other evaluation tools, check out the Accessibility Insights Documentation.

Manual Testing Methods

Manual testing is performed by using assistive technologies, such as a screen reader, to access the content of your website. As mentioned before, a screen reader is software that uses a synthesized voice to read the screen’s contents out loud. The user interacts and navigates through the content by using keyboard commands or touch gestures. It is important to note that screen reader users do not use the mouse. Therefore, you will not be using the mouse when you test. There are options for free or paid screen readers that you can use. Below is a list of screen readers that we recommend for accessibility testing.

On Windows, JAWS is the most popular screen reader in the U.S., NVDA is a comparable free open-source screen reader with worldwide popularity.
On Mac and iOS, Voiceover is built-in and is popular among the blind community.
On Android, Talkback is the built-in screen reader.

Each screen reader has robust support and training materials available. See the resources section below. The MOPD Manual Website Testing Guide gives step-by-step instructions on how to conduct manual testing and provides information on additional tools for manual testing.

Resources

Below you will find resources to advance your accessibility journey. This list is not an endorsement of these organizations, companies, or resources; nor is it exhaustive.