Web accessibility is an incredibly vital aspect to consider when developing a website or web application, yet so many companies either ignore accessibility guidelines or don’t understand how to implement them properly. Some argue that making your site accessible is a moral obligation. All people, regardless of ability or disability, deserve to be able to use the internet and to access the wealth of knowledge that can be found there. Others take a more pragmatic approach and argue that accessibility can be treated as a financial problem: is the return on investment for making your site accessible worth it? By not following accessibility guidelines, you risk alienating users with disabilities and losing their business. So, is the engineering cost worth the potential lost market share? Personally, I fall into the first camp. I believe we all should feel morally obligated to make our sites as accessible as possible. Not necessarily because it is the most financially sensible thing to do, but because it is the right thing to do. (Especially if your business is in the education space or provides an essential service. By not creating accessible content, you are in a sense saying, “Those with disabilities are not worth educating. You are not worth our time or attention.”) I think, deep down, we as developers want to do the right thing. The problem then stems largely from the fact that many developers do not have any experience making their sites accessible or do not know how. For instance, have you ever tried to use a screen reader on your site? Or do you know how to use a screen reader at all? Do you know what tools are out there to help audit your site for accessibility issues? Do you know and understand what guidelines you should be following? Web Content Accessibility Guidelines (WCAG) The , commonly referred to just by its acronym, WCAG, are a set of guidelines and recommendations for how to make your web content more accessible. The current version of this document at the time of this writing is WCAG 2.1. Web Content Accessibility Guidelines WCAG is published by the Web Accessibility Initiative (WAI) group, which is part of the World Wide Web Consortium (W3C). Like most things from the W3C, the document is quite meaty. It’s a very technical document, very long, and potentially exhausting to read. WCAG 2.1 offers 4 principles and 13 guidelines for how to improve your site’s accessibility. In this article, we’ll briefly go through each of these points. By the end of reading this article, you should hopefully have a good idea of what guidelines you should be following and be able to see some areas of “low-hanging fruit” that would be quick wins for you to implement on your own site. WCAG 2.1 Principles Photo by Sarah Shaffer on Unsplash WCAG 2.1 outlines four principles of accessibility. Websites must be erceivable, perable, nderstandable, and obust ( ). P O U R POUR For content to be , users must be able to perceive that the content exists. It cannot be hidden from users that aren’t able to use all of their senses. perceivable For a user interface to be , users must be able to operate and navigate the site, regardless of whether they are using a mouse, keyboard, or screen reader. operable For information to be , users must be able to understand the content on the page and also understand how to operate the page. understandable For a website to be , users must be able to use the site on a wide variety of devices, screen sizes, and browsers, including when used with assistive technology. robust Now that we understand at a high level what the guiding principles of web accessibility are, let's dive into the details of each principle. That’s where the 13 guidelines come in. 1. Perceivable Photo by Yassine Khalfalli on Unsplash To make your content perceivable, here are some guidelines to follow: Guideline 1.1 Text Alternatives Provide text alternatives for any non-text content on the page. For example, non-decorative images should have an attribute that describes the image. (Decorative images like background images can just have an attribute with an empty string as its value.) alt alt Guideline 1.2 Time-based Media Audio and video clips should include captions or transcripts to help the blind and deaf. Guideline 1.3 Adaptable Content should be able to be displayed in different ways and in different layouts without losing information. For example, the HTML structure of your website should read in a sensible order if you were to strip away all the CSS. When a user is viewing your site on a mobile device or tablet, the viewport orientation shouldn’t be restricted to landscape-only or portrait-only. Guideline 1.4 Distinguishable When presenting information such as errors while a user is filling out a form, use a combination of color and icons so that colorblind users can still understand your messages. Color should not be the only visual means of displaying information. Color contrast between foreground and background should be appropriate (in general, at least a 4.5 contrast ratio is what you should be shooting for). If audio plays on your site for more than three seconds, the user should have the ability to stop the audio or to change the volume. A user should be able to change the font size on the screen without breaking the site layout. A user shouldn’t have to scroll both vertically and horizontally to see content on the page. Buttons and inputs should have hover and focus indicators so the user knows what element is currently active. (This guideline covers a ton of stuff!) 2. Operable Photo by Nhu Nguyen on Unsplash To make your UI operable, here are some guidelines to follow: Guideline 2.1 Keyboard Accessible A user should be able to use and navigate your website using only their keyboard. You can easily test this yourself by just using the Tab, Enter, Space, Escape, and arrow keys on your keyboard when visiting your own site. Can you reach every button and input on the page? Can you click every button on the page by using the Enter or Space key? (Please don’t do silly things like add click listeners to divs and spans!) Do you fall into any focus traps where you have no way to get out of a specific area of the page? Remember that not everyone uses a mouse. Guideline 2.2 Enough Time Users need enough time to read the content on the page and to respond to notifications. If you have toasts that appear in your application, don’t make them disappear after a few seconds; let them stay on the page until a user dismisses them. If a user’s session is about to expire, warn them in advance and give them a way to extend their session. Unless time-based functionality is absolutely crucial to your application (for example, a ticket reservation site that only allows you to hold tickets before purchasing them for so long), don’t use timers or time limits at all. Guideline 2.3 Seizures and Physical Reactions This one should be fairly straightforward. Don’t do things on your site that are known to cause seizures. Don’t have content that flashes more than three times. Don’t include frivolous animations just for fun. Any sort of movement on the page should serve a purpose and should be carefully considered. Guideline 2.4 Navigable Make it easy for users to navigate your site. Add a “skip to content” button for keyboard users that allows them to skip the nav links and go straight to the main page content. Use proper heading levels, and don’t skip heading levels! (An element should not follow an element without an element first.) The headings are incredibly important for screen reader users. h3 h1 h2 Make sure when tabbing through your site, the focus order makes sense. As mentioned earlier, focus indicators should be visible so that the user knows what element they are currently focused on. Your page should have a title. Breadcrumbs should be used so the user knows where they are in your site and how they got there. Guideline 2.5 Input Modalities Users should be able to operate inputs with their keyboard on a desktop/laptop as well as with a touch screen on a mobile device or tablet. Don’t make buttons too small on mobile device screens so that it is difficult to press the correct button. A good minimum size for touch targets is at least 44 x 44 pixels. 3. Understandable Photo by bruce mars on Unsplash To make your information understandable, here are some guidelines to follow: Guideline 3.1 Readable Your target audience should be able to read and understand the text on the page. Avoid jargon without including explanations. Use a proper attribute on your tag to define the language in which you are writing. Use the tag for abbreviations. lang html abbr Guideline 3.2 Predictable Make sure your website behaves in a predictable way. Be consistent in what your buttons look like and what your links look like. If you have a global navigation component that displays on every page, make sure the links are always in the same order and in the same place. If components look the same, they should behave the same. Guideline 3.3 Input Assistance You should help users avoid and correct mistakes when using your application. Use labels on all your inputs. Use placeholder text where appropriate, but don’t use placeholder text in place of a label! When a user is filling out a form, provide helpful feedback messages as soon as possible. Identify exactly which input has the error and how the user can correct the error. For long forms or multi-page forms, allow users to review their data before the final submission step. 4. Robust Photo by Hal Gatewood on Unsplash To make your website robust, here are some guidelines to follow: Guideline 4.1 Compatible Your site should be compatible with a wide range of user agents and should be as future-proof as possible. Use correct HTML so that your content is parsed correctly. Use semantic HTML elements so that screen readers can better understand your page structure. Use elements with and to provide screen readers with updates on the success or failure of actions as a user is interacting with your app. role=status role=alert Bonus: How to Test for Accessibility At this point, you know all the principles and guidelines contained in WCAG 2.1. But now what? Where do you start? How do you go about evaluating how well you are doing at making your website accessible? Below are some ideas, tools, and extensions that I’ve found helpful: Manual Testing for Keyboard-Only Navigation As suggested earlier, imagine you don’t have a mouse. Try to navigate your site using only your keyboard. This should provide some quick insights into which areas of your site are not navigable or operable for keyboard users. Manual Testing with a Screen Reader If you don’t know how to use a screen reader, get acquainted with one. Popular choices include , for iOS, and for Windows. It can be difficult at first to learn how to properly use a screen reader, but it is well worth the effort. JAWS VoiceOver NVDA Once you understand the basic commands for your chosen screen reader, try using it on your site. You will quickly learn how frustrating it must be to be a blind user of the internet. Chrome Extensions The can provide analysis of any page and helps catch many accessibility issues. A complete list of their rules can be found in their . axe Chrome extension GitHub repo The is a similar extension that can also analyze your site for accessibility issues. Accessibility Insights for Web Chrome extension eslint-plugin-jsx-a11y You can use the ESLint plugin to lint your JSX for accessibility issues. Simply add and this plugin to your package’s dev dependencies, along with any other plugins you typically use, and you’re all set. Like every other ESLint plugin, this one can be configured to produce either warnings or errors based on accessibility rules that you choose to follow. eslint-plugin-jsx-a11y eslint Conclusion If you’ve made it this far, thanks for reading! I hope by now you understand the motivation for making your site accessible, the principles and guidelines you should follow, and how you can do some accessibility testing. Now get out there and make the world a better and more accessible place! Previously published at https://levelup.gitconnected.com/wcag-2-1-simplified-how-to-make-your-website-accessible-1cfadd03d20d

Target

Dependency Injection to Make Your Code Testable [A How-To Guide]

An Introduction to Test-Driven Development

How to Make Your Website Accessible: WCAG 2.1 W3C Recommendation

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

100 Pieces of Programming Advice from the Book Clean Code by Robert Martin

63 Stories To Learn About Accessibility

Lets Make an Internet for Everybody

Badger Accordion — An accessible light weight, vanilla JavaScript accordion with an extensible API

Colour and contrast — The 2 essential ingredients of accessible design

100 Pieces of Programming Advice from the Book Clean Code by Robert Martin

63 Stories To Learn About Accessibility

Lets Make an Internet for Everybody

Badger Accordion — An accessible light weight, vanilla JavaScript accordion with an extensible API

Colour and contrast — The 2 essential ingredients of accessible design

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps