Although we have talked about the business case for investing in web accessibility at length, it is also important to consider the reasoning behind making your site compliant from a legal perspective. With accessibility lawsuits at an all-time high, now's the time to assess if your website experience is fully accessible.
In this blog post, we will briefly touch on the warnings and legal actions your organization may face by failing to meet compliance requirements for accessibility in your digital assets website, and apps. We’ll also provide solutions that content editors and developers can employ to make a website more accessible to the public.
Accessibility Warnings and Lawsuits
Organizations in many industries face challenges in making their website experiences accessible. They may have started with accessibility baked in but, as the content was updated and added, lost track of continuing on a pathway toward accessibility. In any case, some organizations may face scrutiny from governing bodies. For instance, the Department of Education may send a warning to a university or college about their accessibility issues, with the understanding that the organization will do what it can to address those issues sooner than later.
High-Level Changes for Website Accessibility Compliance
If you are a content producer or editor, some of the changes you can make listed below will provide your users with more accessibility features.
Color contrast
Color contrast is an important consideration when trying to make your website more accessible. It is estimated that one in twelve people cannot see the average full spectrum of colors, according to an article on color contrast from Deque University, so using color as the only indicator on a site or choosing colors on the site for the foreground and background that are too close together could alienate these users.
WCAG compliance for color contrast can vary, depending on if you are seeking Level A, Level AA, or Level AAA compliance; however, typical contrast ratio benchmarks of at least 4.5:1 for normal text and 3:1 for large text can be applied.
Alt text for images
Alternative text, often referred to as alt text, is used to give meaning and context for images and other media within a webpage. They are especially important when thinking about accessibility because screen readers use alt text to give users an idea of what the images mean.
Some best practices for using alt text in your site include:
- Leave out the words “image of” or “picture of” because screen readers will already indicate that the user is interacting with an image so adding those words may lead to duplicate content.
- Use short descriptions of around 125 characters.
- Consider whether or not the image is purely decorative. If this is the case, you can leave the alt text blank (alt=””). For images that should always have alt tags, like articles or bios. Ask your developer to make the alt field required so they don’t get skipped.
Headings
Headings provide structure to a page in that they can be used to separate sections and also guide screen readers to better understand the context of the content ahead. Some screen readers allow the user to navigate through the webpage by headings, so it is important to provide descriptive headings whenever possible and to put them in the proper order. Every page should begin with a heading level 1, or H1, followed by H2s which support the main idea and, should the levels underneath these headings continue, H3s that support these ideas in a semantic way. The headings after H1 should be “nested” meaning H2s should have related H3s below them. Here is an example:
H1
H2
H3
H3
H2
H3
H4
Labels
To make a page accessible, one must consider all types of accessibility, including making forms accessible. This may mean reviewing your page to see if you are using the
Labels provide context for screen readers and allow the user to properly navigate the page and fill in information when needed or select relevant information in the form. For instance, if my form includes checkboxes, I need to make sure that they are labeled properly.
Labels are a nuanced subject more widely covered in the following blog posts on the Mediacurrent site:
Accessible Names - Label All the Things! (Part 1)
Accessible Names - Label All the Things! (Part 2)
If you are a content editor or work in a role outside of development, check out our accessibility ebook for non-developers! It’s full of great information and guidance to help you create a more accessible site.
Developer Accessibility Considerations and Quick Wins
Site developers really should be building sites with accessibility in mind. But often they are maintaining code that they didn’t create themselves or is older and was done before accessibility was on many developer’s radar. Also, be careful that you consider accessibility when selecting third-party frameworks or APIs.
A site audit with automated tools and manual testing is very helpful in documenting issues and tracking their resolution. Check out our blog post about website accessibility checkers for more tools and resources.
Developers are tasked with addressing code level accessibility issues; maps, image carousels, animation, and other complex elements may require some custom code to be accessible. Many of the accessibility issues covered in this article are related to :focus, meaning a user should be able to move focus to Interactive elements like links, buttons, navigation with any input device; keyboard, mouse, touch, voice, switch device, etc. Luckily, simply adhering to best practices on common HTML elements goes a long way to being compliant. Follow these best practices to make some quick accessibility wins:
Test as you go
Don’t wait until the end to check if your site or new feature is keyboard accessible. Testing your work as you go will allow you to identify errors early in the process when fixing them is usually a simpler task. This should include both automated (like WAVE or Siteimprove) and manual testing. If you are lucky enough to have a dedicated QA team, they can help verify your work as well!
Use the right tag for the job
When your code conforms to HTML standards it is more likely to work with assistive technologies. In fact, HTML is the most accessible format for content. This may seem obvious, but as a reminder, there are six HTML elements that by default can receive focus. So unless there is a really specific reason not to, developers should use these elements to ensure proper keyboard accessibility:
These HTML elements are focusable by default:
<a>elements with an href attribute<link>elements with an href attribute<button>elements<input>elements that are not type="hidden"<select>elements<textarea>elements
Links and buttons
Keep in mind that links and Buttons are both focusable, but semantically different. Be sure to use the A tag for links which are focusable and triggered by the enter key. Links typically redirect to another page. While a button will typically trigger an action like opening or closing a modal or submitting a form.
Great in-depth source:
Document and website structure from MDN Web Docs
When to use non-semantic wrappers
At the same time, you shouldn’t use these sectioning tags incorrectly. There are situations where there isn’t an ideal semantic element. In these cases, using the tried and true DIV tag is the right call. Divs are block level elements and are perfect for grouping related content or functionality. Spans are non-semantic inline elements and are typically used to wrap text or other inline elements.
If any of these elements need to be keyboard accessible, the easiest method to add an item to the TAB tree is to add the tabindex=”0” attribute. Just note that manipulating tabindex can get tricky so it’s best to rely on the elements that are focusable by default.
Page structure
While content editors are key in structuring page content using Headings, alt tags for images, adhering to color contrast rules, developers should make sure to properly structure a document using semantic tags. These tags are used to section off parts of your page based on their functionality, making it screen reader-friendly. I’d like to think most developers are familiar with this but let’s cover the basics. Plus you may find older codebases where semantic elements need to be added to be compliant.
The key HTML sectioning elements are:
<header>introductory content like branding and site navigation<nav>Identify navigation<main>indicates main page content (once per page)<section>group common page elements<article>wrap article content, may include sidebars<aside>wrap sidebar type content<footer>contains last elements on a page, copyrights, etc
Using ARIA landmarks
Developers use WIA-ARIA to provide extra semantic information about an element. WAI-ARIA stands for Web Accessibility Initiative — Accessible Rich Internet Applications (WAI-ARIA). Commonly used attributes are aria-label, aria-labelledby and aria-describedby, which are often used to make form inputs or other interactive elements more accessible. A couple of ARIA labels that are really useful to have in your toolbox:
Avoid redundant links: aria-hidden=true
It’s not uncommon to have a link repeated several times on a page. You might have an article teaser which includes a photo and headline, it’s common to link both the image and the heading to the article. But for screen readers, this means the same link will be read twice. To avoid this duplicative behavior, simply adding aria-hidden=true to one of these links, the link will still work fine, it is only ‘hidden’ from the screen reader.
Add form labels easily: Aria-labelledby
WIA-ARIA is too broad a topic to properly cover here, I would encourage you to learn more here: Using ARIA: Roles, states, and properties by Moz
Keyboard accessibility
Some of your site visitors may have a permanent or temporary impairment which means they rely on the keyboard to navigate a page. Here are some strategies to ensure they can navigate your site.
Test for TAB, SHIFT+TAB, ESC (:focus)
Keyboard users, use the tab, enter, shift + tab and esc keys to explore your page. As they tab through your page, each interactive HTML element (an input item such as a field, checkbox, button, or link) should have a visual indicator when they receive input from the keyboard. This is typically called focus.
Sadly, a common issue we discover when doing site audits is that accidentally or for aesthetic reasons, the focus indicator or ‘focus ring’ has been hidden from some or all such elements. If your mega menu has no :focus style, that can affect your entire site and leave you open to legal action.
In fact, a single line of CSS like: :focus { outline: none; } can make a site very difficult for people who use the keyboard to navigate an entire site. So be sure to search your codebase for ‘outline: none’ and manually test for gaps in focus indicators. This is a really simple best practice to follow and impacts other items we will cover.
TAB Order (Source order)
As a visitor TABs through a page, the order of each focusable element is important, this is the Tab Order. If the focus jumps up and down a page, a visitor will quickly get lost. So be sure the source code flows in the correct, logical order of how a visitor would expect to navigate the page. You can also use tabindex=”0” or “-1” to manually add or remove elements from the Tab Order if required. That said, it’s a best practice to avoid tabindex=”-1” as much as possible.
This is also an area where using header, main, footer sections plays a key role.
Skip link
It is also a best practice to include a skip link at the top of the page. This is a helpful link for keyboard users and allows them to press enter to skip the page header/menu and navigate right to the main page content. This skip-link should be visually hidden for most site users and only be displayed when using the TAB key.
Navigation
Making site navigation accessible is a wide topic and beyond the scope of this article. That said, your site nav is one of the first elements that would invite legal action if it is not compliant.
Dropdown menus
Primary site navigation is often multiple levels deep. So setting up the ‘dropdown’ behavior for menu parents is key to remaining compliant. It’s common that the menu parent’s behavior is on hover rather than click. When the user hovers over the menu parent, the child menu links appear - this is considered a pseudo-link.
So be sure that even a pseudo-link is wrapped in the link tag or else it won’t be focusable, leaving the entire menu inaccessible (add preventDefault() to your link so it cancels out the link action). If you can’t add a link tag, then you will need to add tabindex=’0’ to each menu parent.
If you are building a new site (or find it easier to rebuild a menu), there are some great libraries out there that can provide the foundation for a fully accessible menu.
Here are two we have used successfully:
Learn more about accessibility
From audits to remediation, the Mediacurrent web accessibility team is here to help ensure your site meets or exceeds accessibility standards. Contact us to learn how we can support your efforts in achieving website accessibility.