Web Content Accessibility Guidelines (WCAG) 2.1 are a series of guidelines published by the Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C) for making web content more accessible on desktops, laptops, tablets, and mobile devices.

Following these guidelines helps ensure content is more accessible to a wide range of people with disabilities, such as blindness and low vision, deafness and hearing loss, limited movement, and photosensitivity. The guidelines often improve usability for general users as well.

There are a lot of guidelines and they can be hard to understand for those of us who aren’t developers (such as myself) but here are a few of the basics –

Provide text alternatives for non-text content (photos, videos, etc.)

Ensure that there is enough difference between background and text color

Provide user controls for pausing, stopping, or hiding content

Use clear page titles, headings, and labels

Keyboard accessibility for users without a mouse


It’s important to note that there are multiple levels of conformance to the guidelines.

Level A â basic web accessibility features

Level AA â deals with the most common barriers for disabled users

Level AAA â the highest (and most complex) level of web accessibility

Of course, level AAA is ideal. However, some of the highest level guidelines can’t be applied to all websites and therefore level AA is the next best target.

Here at VIA Studio, we have a set of tools and checklists that we use for every web project to ensure that these guidelines are met and that the websites we build are as accessible as possible. It’s important to us that users with disabilities have equal access and equal opportunity while accessing the web.

To see a full list of WCAG 2.1, check out 

https://www.w3.org/WAI/standards-guidelines/wcag/

Accessibility

Quality Assurance

A Brief Overview of WCAG 2.1

Part 1: What is Accessibility? Why should I care?

Part 2: Assessing Your Accessibility (What to Fix)

Now that you’ve assessed your website and have made some improvements on your findings, it’s time to put it to the ultimate test.

During my testing experience, I’ve grown very fond of accessibility testing tools. Not only because it can be hard to put your yourself in the shoes of every possible angle to test for, but also because it can be challenging to determine if the component in question is within the accessibility 

 or not. In this post, I’ll give you some of my ideas, tips, and tools that I’ve collected during my experience with accessibility thus far. Focusing more on the styling and functionality of the site rather than the content.

To make testing a little less intense or complicated, you can download some handy tools for Chrome to help. I have tried a handful of different extensions and kept a couple, 

, in my toolbox for future use. Though these extensions should not be your only means of determining the level of accessibility, they will give you helpful feedback without having to dig into the code in great detail – let your developer do that!

. FreshEyes will give you an idea of how a colorblind user will see the site, depending on which filter you select. When checking here, keep in mind that the color contrast has potential to be more of a concern for a user that is not color blind. You can use Siteimprove along with FreshEyes to help examine this. With Reader View, you are checking to see if all pertinent content is available, as it essentially removes the CSS and JavaScript from the page. If you have content that depends on CSS or JavaScript to display, you want to make sure there is an alternate delivery method available.

 (for free), as well as looking over the 

 capabilities for testing on an Apple product. Hearing how a screen reader presents the components of the site to a user will allow you to determine if they are getting the best experience possible. If it sounds funny to you, it can be confusing to them. Part of me suggests to get familiar with screen readers, if not already, while another part says not to. Some of the frustration you could experience while getting use to these could lend some insight into how a user interacts with a site for the first time. If you feel frustration building up while familiarizing yourself with the shortcuts and gestures, imagine that as the experience a user may have with an inaccessible website.

The last tool is knowledge. Take a look at some information about different 

 to get a better understanding of what users could be experiencing, or what other kind of 

 are used to access the web. If you know someone that may have a disability, impairment, or uses assistive technologies, ask them if they could help in inspecting; real user testing determines the level of accessibility the best.

So, now that you’ve tested your site with the tools mentioned previously, it’s time to put yourself in someone else’s shoes for another round of testing. For desktop or laptop testing, unplug your mouse and set it to the side. Find a blindfold or some DIY impairment specsâa post for these DIY specs coming soonâand go through the site using a 

It might take a few tries to get use to it, but eventually you will be able to identify which areas cause trouble. While doing so, refer back to our 

 post for the questions to keep in mind. Take notes for the areas you find confusing, such as a weird ordering of form fields while using the tab key, to discuss with a developer if further improvements are needed. Include the information provided by the accessibility extensions with the developer as well, to give them specific examples in the code to look over.

I remember a particular lesson in my 6th grade health class, where we went through the different senses and a handful of experiments for each. One of homework assignments that week was to eat dinner while blindfolded. We had to lean on our family for support – to tell us how the plate was laid out using a clock format, mashed potatoes at 12, corn at 2, etc. – and a sort of muscle memory to remember the layout. In a way, that lesson is similar to how a user interacts with a website. Relying on some support, acting as assistive technologies, and muscle memory to help build the layout or placement in a cognitive schematic. With that said, combining the tips and tools I’ve referenced, as well as a general understanding on code semantic HTML in our previous post on (

), will give you a great starting point to thoroughly test for accessibility. And with some helpful feedback from real user testing added in, your site will be an accessible champ in no time!

There are a lot of tools out there and, obviously, some are better than others since they are not all the same. Don’t rely on just one of these tools, because it may miss something that another will not. And although they may report issues, it’s ultimately up to the human perspective to recognize the priority of the accessibility.

User Testing

Website Accessibility: Testing (Part 4 of 4)

Branding

Web Design

WordPress

Hubspot

Collateral

GoodMaps

Photography

Websites

Art Direction

Treyton Oak Towers

Accessibility is a broad concept, but it's best described as providing a quality, functional experience to as much of an audience as possible. At VIA Studio, we consider usability from the very first moment of any projects. In practical terms, this means deep understanding of our assumed audience, followed by user-focused design, WCAG- and ADA-compliant frontend development and finally detailed accessibility-minded quality assurance.

Accessibility

Accessibility: Case Studies

01

GoodMaps

02

Treyton Oak Towers

Accessibility: Blog Posts

A Brief Overview of WCAG 2.1

Website Accessibility: Testing (Part 4 of 4)