A well-designed website isn’t just one that looks good. Even a website that converts effectively isn’t enough. These days, websites need to be accessible for all users, including those experiencing disabilities, limitations, and impairments.
Web accessibility is a dense topic that requires time, resources, and commitment to attain on a business website. Even so, ensuring equal access to your website truly does matter from an ethical, financial, and legal perspective.
That’s why the Web Content Accessibility Guidelines (WCAG) were created — this comprehensive resource provides actionable instructions to build a website that accounts for the diverse range of challenges faced by millions of internet users. If you want to know where your site stands in terms of accessibility, look to the WCAG.
Even with the help of resources like the WCAG, getting started with accessibility can be intimidating. So, in this post, you’ll learn how to conduct a simple, routine accessibility check based on WCAG guidelines.
The best time to incorporate accessibility into your website is at the start of the design process, but the second best time is now. So, let’s dive in.
.png)
Website Accessibility Checklist
This checklist will help you make the following more accessible on your website:
- Web Pages
- Navigation
- Video & Media
- And More!
Download Free
All fields are required.
What is a website accessibility check?
A website accessibility check is a brief evaluation of a website’s accessibility. An accessibility check assesses a site’s current adherence to WCAG guidelines and identifies areas for improvement.
Accessibility testing can be done manually or with an automated testing tool. Automated testing is fast, free, and simple, but not comprehensive. So-called “accessibility checkers” can pinpoint common problems with accessibility, but it’s impossible to address all WCAG criteria — and even some fundamental criteria — with an automated tool.
According to HubSpot Senior Web Developer David Ding, automated accessibility tests work “with the huge caveat that they must be complemented with manual testing, as they will definitely not catch everything. In particular, keyboard navigation for interactivity that is even slightly complex needs to be tested manually.”
So, while manual accessibility testing takes more time and effort, it is ultimately the more robust method for finding problems. We recommend conducting routine manual accessibility checks assisted by automated tools.
How long does a website accessibility check take?
How long your accessibility check will take depends on your website’s size and your level of adherence to WCAG criteria. In the following section, we’ll give guidance for how to reach WCAG AA conformance. Note that AA conformance is far from perfect accessibility and should be understood as a baseline.
These guidelines can be applied to websites of any size. But, the larger the website, the more work is needed for a thorough accessibility check. To save time, focus first on the pages on your site with the most traffic, likely your homepage and landing pages. Optimizing these pages will have the greatest impact on your site’s accessibility. After that, you can prioritize the pages you review by traffic level until you’ve checked them all.
On top of individual pages, you should also be testing processes on your website that span multiple pages. In your testing, run through common user scenarios like signing up for a service, purchasing a product, finding an article, or conducting a site search.
How to Run a Website Accessibility Check
In this section, we’ll explain how to complete a basic accessibility check that addresses common accessibility problems in key areas of your website. The review process is manual, but can be aided by an automated accessibility checker like the Web Accessibility Evaluation Tool (WAVE).
Title
When conducting an accessibility check, your page title is a good place to start. The page title appears at the top of the browser window and is also shown in bookmarks and in search engine results.
A good page title helps visitors understand where they are on your website — it communicates the purpose of the page so users know they’re in the right (or wrong) place. The page title is also what appears in browser tabs along the top of the browser window. Alongside the favicon, it helps users locate the right tab if they have multiple tabs open.
Most relevant here, the title is the first thing on the page read to users by screen readers, and gives context to those who may not be able to view the entire web page at once.
A page title is concise but contains enough information to describe the page and its purpose. Each title should also be unique from others on your website. Otherwise, you risk confusing visitors while they try to navigate. For example, the HubSpot Blog uses article titles as its page titles:
-4.jpeg?width=650&name=How%20to%20Run%20a%20Website%20Accessibility%20Check%20(According%20to%20HubSpot%20Developers)-4.jpeg)
How to check: Page titles are designated in the page’s HTML by the <title> element. Every page on your website should have exactly one <title> element inside the <head> section. Otherwise, the browser will show the filename of the page you’re viewing.
You can either look at the HTML files of all your pages to check that the <title> element is there, or, for each page, simply open the page in your browser and see what appears in the tab bar.
A tried-and-true approach to writing page titles is to put the most important identifying text at the start of the page title, as this part won’t be cut off by the browser tab. For example, instead of “Jamie’s Personal Website - About Me”, a better title would be “About Me - Jamie’s Personal Website”. This ensures that visitors can always see “About Me” in the tab bar.
Keyboard Controls and Focus
A lot of people use the mouse to get around websites, but not everyone interacts with the browser this way. Many users cannot or prefer not to use the mouse because of a visual impairment, motor impairment, or other physical limitation or injury. Instead, these users navigate with keyboards, refreshable braille displays (pictured below), voice input, or other input devices.
.jpeg?width=650&name=How%20to%20Run%20a%20Website%20Accessibility%20Check%20(According%20to%20HubSpot%20Developers).jpeg)
To accommodate these users, every page on your site should be usable exclusively through the keyboard. Visitors must be able to engage with any interactive part of your website without needing to touch a mouse or trackpad. This applies to all buttons, menus, links (including both text link and image links), forms, and media controls.
When using a keyboard, users typically navigate with the tab, shift, arrow, and enter/return keys, which move the focus from element to element on the web page. Focus is the state of being selected — when an element is in focus, it can be controlled by the keyboard.
Sighted visitors should be able to see which page element is in focus with a visual indicator. Most browsers represent focus with a colored border around the focused element.
-3.jpeg?width=650&name=How%20to%20Run%20a%20Website%20Accessibility%20Check%20(According%20to%20HubSpot%20Developers)-3.jpeg)
Many websites improve keyboard navigation by allowing keyboard users to “skip to content”, bypassing the main navigation menu. This option means visitors don’t need to tab through potentially dozens of menu links on each page to reach the main content.
-2.jpeg?width=650&name=How%20to%20Run%20a%20Website%20Accessibility%20Check%20(According%20to%20HubSpot%20Developers)-2.jpeg)
How to check: To test keyboard accessibility on your site, open a page and use the tab key and arrow keys to advance through the page, shift-tab to go backward, and enter/return to select. (You may need to enable keyboard controls in your browser to do this.)
Try to select every interactive element on the page with the keyboard alone. Anything you can click with a mouse should be reachable, and the visual focus should always be apparent. Take note of elements that are particularly difficult or impossible to access with the keyboard — common culprits include interactive media, drop-downs, forms, sliders, and pop-ups.
In your check, pay special attention to your main menu, as this is the primary means of navigating your website. As HubSpot Senior Developer Advocate Jonathan McLaren puts it, “One of the most critical parts of a website to review during an accessibility check is your main menu, specifically keyboard navigation and screen reader testing. If your main navigation is not keyboard-navigable or is incomprehensible using a screen reader, it’s the digital equivalent to putting up a barrier blocking specific customers from entering your store. If they can’t get to the information they’re looking for, they’re going to go somewhere else.”
As you tab through the page, make sure that the progression through the page elements is logical and predictable, and not jumping around the page. A general left-to-right (or the opposite if the page is in a right-to-left language) and top-to-bottom movement is most intuitive.
.gif?width=650&name=How%20to%20Run%20a%20Website%20Accessibility%20Check%20(According%20to%20HubSpot%20Developers).gif)
Additionally, HubSpot Senior Software Engineer Shea Hunter Belsky recommends looking out for focus traps: “In a focus trap, assistive technology is unable to meaningfully move about a webpage, and gets stuck on a particular element (or it loops between focusing on a few different elements). Users aren't able to go backward or forward, and have to refresh the page and hope they can avoid the focus trap in the future.” Check that you can tab out of any element that you tab into — don’t keep users inside one region, like a menu, without letting them move to another.
Finally, take your testing beyond a single page: Try completing a process, such as signing up for a newsletter or completing a purchase, without using the mouse. Not only does this give you a better sense of keyboard accessibility, but it also helps build empathy for users on your site.
Website Accessibility Checklist
This checklist will help you make the following more accessible on your website:
- Web Pages
- Navigation
- Video & Media
- And More!
Download Free
All fields are required.
Image Alt Text
Alternative (alt) text is a brief text description of an image on a web page. Alt text appears in place of the image when the page is accessed by assistive technology. For instance, a screen reader will read the alt text aloud to provide context for users who can’t view the image itself. Alt text is also displayed if an image fails to load on the page, or if the user has images turned off in their browser.
Alt text is placed in the HTML as an alt attribute within the associated <img> tag. For example:
But, you don’t need to worry about knowing how to edit HTML to insert alt text. Most content management systems and website builders provide a way to add alt text without touching the code.
Alt text should accompany all non-decorative images — in other words, any image that gives information to the visitor, such as an image in the body of a blog post, a photo on a product page, an infographic, or a diagram.
Decorative images, like a background image, don’t need alt text, since they only add style to the page without any additional info. However, these images should still use an empty alt attribute (alt=“”), as this tells screen readers that the image is decorative and not an image that is missing alt text.
How to check: Web accessibility checkers are helpful here — they can identify which images have the alt attribute and which images lack it. In WAVE, plug in the page URL and start the scan. In the results, look for green icons that indicate instances of images with alt text or null alt attributes, and red icons that indicate images with missing alt text.
Note that an accessibility checker can detect whether alt text exists, but it can’t tell you if the alt text is well-written. That’s more of a subjective call that depends on the image and the context it appears in. For tips on how to write effective alt text, see our full guide to image alt text.
Captions and Transcripts
Captions are another important accessibility feature you should check for. They provide a text alternative to speech and audio in a video and display in-sync with the video as it plays.
All videos on your website with sound require captions to be accessible. They’re necessary for people with hearing impairments to fully understand your video content. Plus, they’re helpful for users who need translation, people watching with the sound off, and those who just prefer captions with their content.
Well-written captions include all dialogue (with the attributed speaker indicated) along with other sounds that are necessary to fully experience the video.
Additionally, your website might call for transcripts. A transcript is audio content translated into static text. It’s used for videos and other audio to provide a text alternative for those who can’t listen to the media. Like captions, transcripts contain the words people say and descriptions of other relevant sounds. They’re common with podcasts — an episode page may contain both a media player and a transcript of the episode.
How to check: Conduct an audit of any videos and/or listenable media on your website. View each video and check the media controls for a closed captions (CC) button. Is this button keyboard-accessible?
If captions exist, check that spoken dialogue and other important sounds (such as music) are included in them. If not, create captions that sync properly with the audio. Auto-generated captions are not sufficient, as they’re often inaccurate.
Color Contrast
If a designer isn’t careful with their color choices, the background of a web page may obscure the text due to insufficient color contrast. If you’ve ever tried to read light-colored text on a white background, you know how annoying this can be.
Color contrast is the difference in brightness between a foreground and background color. If the contrast between the text color and the background color is too low, users with visual impairments like low vision or color blindness may have difficulty reading the page.
To provide proper contrast, WCAG requires that normal text has a contrast ratio of at least 4.5:1 with the background and that large text (18 pt or more, or 14 pt or more if bold) has a contrast ratio of at least 3:1.
.png?width=650&name=How%20to%20Run%20a%20Website%20Accessibility%20Check%20(According%20to%20HubSpot%20Developers).png)
How to check: Since your website may feature several combinations of text color and background color, it’s important to check each one’s contrast ratio. An accessibility checking tool can detect some instances of insufficient contrast, but know that it may not be exhaustive.
For each color combination, use a contrast ratio checker like this one from WebAIM. Plug in the hex value for your foreground and background color (or use the convenient eyedropper tool) and check that the ratio between them meets WCAG requirements.
Another option is the A11y Color Contrast Accessibility Validator — enter the URL of your page and you’ll be given a list of contrast errors to fix.
Animations and Flashes
Animations and other visual effects can make pages more engaging, but they also post accessibility issues for some users. Rapidly flashing content may trigger seizures in users with photosensitive epilepsy, and moving elements can be distracting or difficult for users to understand. Information that updates dynamically on the page, like in a news feed, poses similar barriers.
How to check: You don’t need to avoid moving elements on your website altogether, but users should have a way to pause the movement if the animation begins automatically and is longer than five seconds. This applies to scrolling text, image carousels, CSS animations, videos and gifs, and animated infographics.
Additionally, WCAG states that an element should not flash more than three times per second — remember this if any part of your UI flashes color, and consider whether this flashing is necessary. If a message is urgent, for example, flashes could be removed in favor of large text and colors like red or yellow
Text Resizing and Zoom
To view page content more easily, visitors often zoom in on the web page and/or increase the size of the text. Modern browsers allow users to do both of these things, but it’s your responsibility to ensure your website still looks good when your pages are resized.
WCAG requires pages to be zoomed in 200% and still be usable without assistive technology, and that text may be resized up to 200% without assistive technology. Also, this zoom should not undo any other accessibility measures on the page.
How to check: First, open your web page in a browser and zoom in on the page. How do the page contents look at various zoom levels? If items look jumbled, overlapping, or hidden, this needs to be addressed. Try completing some common tasks with both the mouse and the keyboard and gauge if they are still easy. Also, take note of any horizontal scrolling that appears as a result of zooming in, and try to mitigate this as well as it adds interaction cost.
After testing zoom, try resizing the text up to 200% of its original size and conduct the same tests as you did for zoom. Make sure you can still read all text and interact with all page elements as you would with the default text size.
Checking for Accessibility
It’s important to remember that accessibility checks aren’t exhaustive, and you won’t come away with a perfectly accessible website — that requires a much greater investment and probably consulting with experts.
Instead, these checks help you identify the most prominent and fundamental accessibility challenges, then address them. As you improve your accessibility measures over time, you can begin to focus on achieving a higher level of WCAG conformance.
