Skip to content
Malouf Developer Docs

Introduction to WCAG

There is a long and rather detailed history around making the web accessible. There are many points of view, and there are some strategies that may work better in theory, but in practice turn out to not be as helpful or worse for those who need options than if they were not implemented.

An example of this is the use of overlay widgets, such as the widget offered by “Userway”. Great in theory, but in practicality and use becomes a beacon to draw those of the patent-troll ilk to quickly “sue and settle”.

Compliance does have a design cost and there will be times where you will walk on a wire or stand on a virtual land-mine to “protect the brand”, but if we have done everything we can to mitigate these issues and provide the best experience possible for all we should be “winning”.

How to get started? There is a ton of things to do, but here is the basic formula:

  • Semantic elements for the win
  • Use aria attributes as needed to fine tune the markup
  • Label your inputs
  • Know the difference between a link (goes somewhere) and a button (does something)
  • Turn off styles and see if the page still works
  • Use the screen reader on your phone or computer (macOS/iOS has voice-over built in, Edge has a ‘read to me’ feature)

The Web Accessibility Initiative (WAI)

The Web Accessibility Initiative (WAI) is the concentrated group effort of organizations, developers, and is the official agreement of the W3C. Sponsored by big names such as HP, IBM, European Commission, Ford Foundation, and the US Department of Health and Human Services this is the place to go when you want to get directly involved with the spec, and to be informed on all official recommendations.

WAI has excellent write-ups and explanations of why accessibility matters and offers views from perspectives you may not have considered that will help you build the best experience possible for everyone.

I highly recommend a read through the Accessibility Fundamentals Overview.

WCAG “Quick Reference”

WAI has put together a very handy sub-section of their site as a quick reference that can be viewed here.

In practice, this is anything but quick, however it is an essential part of looking up and understanding the minimum requirements set to meet WCAG 2.1 AA standards.

Tools

Old are the days when we had but the AIM checker and a ton of manually process. These days, Lighthouse (Chrome/ium DevTools), Firefox DevTools, services such as WebPageTest, and many browser extensions exist to help you track and manage the changes needed to be in compliance.

The following tools are the ones I use the most, however WAI also keeps a list of ~100 tools here that may be worth investing some time browsing.

axe DevTools by Deque

Available as a browser plugin this handy little tool helps you scan entire pages (or just a section of a page) for code-detectable WCAG violations. It also comes with a manual report wizard to help you manually check those hard-to-detect issues that you may have.

Install axe DevTools for Edge here

Install axe DevTools for Firefox here

Install axe DevTools for Chrome here

Accessibility Insights for Web

Similar to the Deque offering mentioned above, this is a tool that the folk at Microsoft put together to help web developers meet the needs that users of all abilities have for a rich and rewarding browsing experience.

Install Accessibility Insights for Web into Edge

Install Accessibility Insights for Web into Chrome

This extension is not available for Firefox 😢, but don’t worry, here is a support doc for all of the accessible features built into Firefox hooray!

Accessible Color Generator

This site helps you see if the colors you have will pass WCAG 2.1, and if not will suggest the nearest color that will. Note that you may want to test the output of this app against the next tool to make sure the math is right. I have had it give me a bad color once, but this is still my favorite of the color contrast tools

View the Accessible Color Generator here

AIM Color Contrast Checker

This one is classic, and it comes with a handy API that you can build into any number of tools to determine if you foreground and background colors are acceptable in terms of contrast.

View the WebAIM Contrast Checker site here

View the WebAIM Contrast Checker API here (returns JSON)

ARIA DevTools

A plugin that allows you to quickly visulize your page in the same way that screen readers read them. I still recommend listening through your projects but this can help speed up the process so you’re not having to listen through the entire page after every change.

Install ARIA DevTools for Chrome (Chromium)

United States Web Design System (USWDS)

The official Web Design System of the United States is a great example of a design system that not only works, but also adds WCAG standards to the components.

One might notice that enough consideration and care was employed in regards to accessibility that a carousel component is not even included on the list; whereas a complete write up on the usage of a dropdown component is finely detailed

The GOV.UK Design System

The United Kingdom also has an official design system that helps them create sites and applications for the populace of the kingdom. Give the official GOV.UK Design System site a visit and view what they have put together for styles, components, and patterns that can be leveraged in your own projects and design systems.

Final words

A11y (accessibility) will continue to evolve and really is more about inclusion than exclusion. Yes, there will be experiences that some users will not be able to use, participate in, or enjoy. But that doesn’t mean that we shouldn’t make their time any less valuable. Use progressive enhancement, work with care, and keep all users in mind.

You got this, now make sure every one else does too!