Photo by Oliver Thomas Klein on Unsplash

An Intro to Web Accessibility

How to start building more accessible web features

Basic accessibility standards are something that every developer should be aware of. It is important that the tools we build are user-friendly, and suit the needs of a diverse audience. But if you’re like me, diving in to accessibility for the first time can seem daunting. Where to start? The widely-accepted standard for web accessibility: WCAG: Web Content Accessibility Guidelines is massive, with a list of guidelines so long the scroll bar is reduced to a teeny tiny blip on the side of the page. In this post, I will walk through some of the basics for tackling web accessibility from a development perspective. If we keep accessibility top of mind throughout the design and development process, it doesn’t have to be so complicated.

At CrowdRiff, I was recently tasked with completing an accessibility audit of one of our platform’s most popular features — image galleries. Image galleries are used by our customers to feature user-generated content from their brand or destination prominently on their website.

CrowdRiff image gallery in action

As a first step, I read up on the the WCAG levels of compliance, which are broken down into three levels:

A Level: Web content developer must satisfy this checkpoint.

AA Level: Web content developer should satisfy this checkpoint.

AAA Level: Web content developer may address this checkpoint.

As a team we decided that we would aim for AA compliance at a minimum, and incorporate any AAA features that fall within a reasonable scope for our project. My next step was to narrow down which guidelines were applicable to the gallery feature, as well as which guidelines we should keep in mind for future projects.

WCAG is broken down into four categories: Perceivable, Operable, Understandable, and Robust. Below are some guidelines that are a good starting point to incorporate accessibility into your project. If you start here, you’ll be well on your way to AA compliance.

🔊 Perceivable — The way your site is seen or heard

• All images should have descriptive alt text, unless the image is purely decorative. For the images in the gallery, I set the alt text to be the photographer’s description of the image.
• Decorative images that provide no information to the user should either have empty alt text (alt=""), or should be set as a CSS background image.
• Resist the urge to completely remove those browser defaults for focused elements! All links, buttons, form fields, tool tips, menu items, etc. should include a focus indicator to allow users to navigate through your site with a keyboard. If you want to have control over when the focus ring appears (for instance, only for keyboard users), here is a helpful post we referenced that outlines how to achieve this effect.

Default Chrome focus indicator

• If any non-text accepts user input, it should have an appropriate name or label that describes its purpose. For instance, CrowdRiff galleries include social media icons that act as buttons. For these, I included the aria-label attribute to describe their purpose: aria-label="Open this image in Instagram".
• Use semantic markup! Many HTML tags have built-in accessibility features that will improve the navigation of your site.
• Structure your header tags in a meaningful way, to assign hierarchy to the most important information on the page, rather than for styling purposes.
• <button> tags will automatically accept focus when navigating through the page using a keyboard. However, if you need to make another element act like a button, adding role="button" to the tag will also do the trick.
• Consider the order of your page elements. When a user navigates through your page using a keyboard or screenreader, the navigation sequence should be logical and intuitive. By default, the order you list your elements on the page will be order of navigation. If you wish to change the order without changing the page structure, you can add tabindex on the element of your choice, and assign a number value to indicate the order in which this element should receive focus.
• Body text links that do not include a default underline should have at least 3:1 contrast ratio from the surrounding text. They should also have an additional distinguishing feature (typically an underline) that is present on hover and focus.
• For readability, consider the contrast ratio for between the text and background on your site. Here is a very handy tool that I have been using to determine if a particular text/background colour combination passes WCAG standards for text contrast.

WCAG standards for contrast ratio between text and background

• All form inputs should have appropriate labels to indicate their purpose.
• Instructions you include on your site should not rely on shape, size, or visual placement to communicate the message. For instance, “Click the square button on the left”, will not be useful information to a blind user.

💻 Operable — Can the user navigate through your site?

• All page functionality should be available using just the keyboard. Tab through your site to ensure that each section can be reached, and all possible user actions can be performed with the keyboard. As I discovered, this can be particularly tricky when handling modals, which we use as a way to view gallery images in fullscreen. In this case, you have to shift the focus to the modal window when it is opened, and ensure focus stays in the modal during the time it is active. You should also return focus to the last focused element once the modal is closed. A great resource for achieving this is available here.
• The keyboard focus should never be locked or trapped. The user should be able to navigate your site freely, without getting stuck in a loop, where they cannot navigate out or away.
• Links with an empty href attribute (or href="#") are not accessible by keyboard. This pattern is sometimes used in dropdown menus, etc. but because the links do not lead anywhere (they link to the current page) they are ignored in keyboard navigation.
• Include appropriate alt text for each link that makes sense to the user even if read out of context. Avoid ambiguous language like click here and instead opt for a concise descriptor that clearly describes where the link leads.

⁉️ Understandable — Does the operation of your site make sense?

• Page language should be clearly identified using HTML lang attribute.
• When the user interacts with a control, it should not result in any change that would disorient the user (unless the user is informed ahead of time). For example, clicking on an image in CrowdRiff galleries will initiate a fullscreen modal with more information about the image. In order to inform the user of this change, we’ve added an aria-label to the image button that describes what will happen if you click: aria-label="Image gallery. Click to learn more about <IMAGE TITLE>".
• Stay consistent. Any controls that are repeated throughout your site should be located in the same place so users can find them quickly and easily. The order of navigation should also be repeated, so there are no surprises to the user. For instance, when the user views one of the gallery images in fullscreen, the navigation arrows to move to the next image, previous image, or close the slideshow are located in the same place no matter what image is clicked. All image information such as the photographer’s social handle, the original caption, location, etc. are located in consistent locations at the bottom of the image.

CrowdRiff Gallery: Fullscreen slideshow view

• When a page element is focused, it should not result in any change that would disorient the user, such as initiating a new viewport or moving focus to another element.
• If there is a validation error on any form field input, suggestions for how to correct the error should be provided to the user.

✅ Robust — Does it work the way you expect it to?

• Keep your code nice and clean. All elements should have complete start and end tags, and be nested appropriately.
• As mentioned above, markup should be used in a way that facilitates accessibility (using forms, form labels, frame titles, etc. appropriately).
• Test your product or website on multiple devices, in multiple browsers, and with assisted technology such as a screenreader, to ensure it is working consistently.

Moving Ahead

Ideally, when you plan to incorporate accessibility into your product or website, you do so before you even start to build. But if you’ve already built something (as we had!) its never too late to go back and reassess. Even while writing this post I have noticed some areas of improvement we could look into. If you’re looking for a place to start with your own project, I’d recommend adding Accessibility Developer Tools in Chrome and running an accessibility audit of your own. Good luck!

Photo credit: Glenn Carstens-Peters on Unsplash