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 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

Quality Assurance is a critical step in creating and delivering work that works as planned and works well for your audience or users. 

At VIA, quality assurance entails the basics such as proofreading, but also highly technical cross-browser and cross-device testing and accessibility testing.

Our Quality Assurance team is deeply invested in your audience and users, getting to know their capabilities, needs, desires, usage patterns and preferred method of interface.

Quality Assurance

Development

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.

Whether your project is an app, a website or even a piece of collateral, it will benefit from structured user testing and the feedback it provides. We have experience with user testing at every level of fidelity, from in-person to groups to remote- and dispersed user testing. 

User Testing

Strategy

Website Accessibility: Testing (Part 4 of 4)

The general idea behind semantic markup from a dev perspective is that you can look at the markup and tell (to a degree) what the inner code is based on what its container is. For instance, I can tell the body of this post is an article because it’s wrapped in 

. This can also be deciphered with the navigation, footer, etc…

 <header> banner <nav> navigation <main> main <aside> complementary <section> region <article> article <footer> contentinfo <form> form

The navigation has to be keyboard accessible and have the ability for tabbing through it. Make sure you wrap it in a <nav> and test the navigation with a keyboard and without a mouse (

Next up is ARIA (a good guide can be found 

Accessible Rich Internet Applications (ARIA) defines ways to make Web content and Web applications (especially those developed with Ajax and JavaScript) more accessible to people with disabilities. For example, ARIA enables accessible navigation landmarks, JavaScript widgets, form hints and error messages, live content updates, and more.



ARIA is a set of special accessibility attributes which can be added to any markup, but is especially suited to HTML. The role attribute defines what the general type of object is (such as an article, alert, or slider). Additional ARIA attributes provide other useful properties, such as a description for a form or the current value of a progress bar.

Simply put, ARIA gives roles to elements, such as an error message, so that screen readers can better describe the element. For instance, I can look at a yellow or red box and tell that it is a message alerting me. However, a user using a screen reader is unable to experience the alert. In this case, we could give the message box the ARIA role of alert. A full list of ARIA roles can be found 

Adding it to elements is trivial, as it is just an attribute.

<div role="alert">This is an important message</div>

 on the subject. We found that a good portion of our forms did not have labels with every input, the navigation messages were not as descriptive as they should be, nor was the tabIndex always in the correct order.

 when you can and make sure the layout of the form is “logical”. More information can be found 

The error messages have to be specific, so validation per field should not be a general statement such as, “there was an error with your submission.” Links in the error message that guide you to the portion of the issue form are preferred.

Website Accessibility: How to Fix It? (Part 3 of 4)

Part 2: Assessing Your Accessibility (What to Fix) â¬

So you’ve heard talks about “Web Accessibility” lately – and maybe you have already read our 

 to learn more about it – so the lingering question is, how do you know if your site is accessible? You could do a Google search and read through the all of the information from 

This post will rundown which areas to examine, what to look for, and how to tell if improvements are needed. We’ll group these into two parts, each with their own sections and questions to ask yourself. If you answer 

 to any of those questions, it is suggested to make improvements to that section.

. Generally, content updates can be made through your content management system (CMS), like WordPress, but some could require a developer to make changes. Unless you have access to the code, a developer will likely be needed for updates in the second part, titled: 

Whether your site’s content is mainly text, images, or a mixture of both, you’ll want to review 

 for accessibility. After all, users are ultimately looking for content, so it goes without saying to keep the following things in mind when creating new content in the future.

You may not realize how important a carefully crafted page title is, but your users do. Page titles are used for orientation, they help the user navigate through the site for the content they’re looking for, and it is the title that shows up if it were in a list of Google search results.

Are my page titles as succinct as possible, while adequately describing the content in a unique (no other similar titles) way?

Are my page titles front loaded? For example, something like “About VIA Studio” instead of “VIA Studio | About”.

Similar to page titles, utilizing proper header formatting is another important factor in accessible content. Yes, you can use your header styles for multiple options to format text, but is that hindering the user’s experience? It could be. Screen readers have a shortcut that will pull up a list of all headers on a page, and if you’re using header styling on areas that aren’t truly section headings, then you could be causing some confusion to the user.

Am I using header styles to call out the different sections in my content? Are they in a logical, hierarchical order?

Am I using other styles (bolding, italicizing, and/or underlining) to help call out other content that isn’t necessarily a header?

Alt text is not only important for SEO purposes, but is a way for screen readers to inform the user of what they may not see. Every informative image, chart, and illustration on your site should have a corresponding alt text attribute to help describe the content to the user. The only time you could omit the alt text is when the element is purely decorative.

Do all of my images/graphics (that are not just decorative) have a corresponding alt text attribute?

Does the alt text explain it in a way that helps the user understand the content?

While you use the web, you run into number of “Click Here” or “Read More” links. As a user without visual impairments, this could be OK link text since you’re able to read or visualize the content surrounding it. However, a user with a screen reader may have trouble gathering what the link is in context to. They may be using a screen reader shortcut to bring up a list of all links on the page or are tabbing through the site with their keyboard. Imagine hearing “Click Here” or “Read More” over and over again, instead of something more descriptive like, “Discover Our History.” Could be frustrating, right?

Are my links using succinct, descriptive text that adequately informs the user of the corresponding content?

Depending on the nature of your site, you may not have a lot of heavy functionality to assess. Some of these sections are a little harder to determine than the ones in the content, so for these, you can take a look at the 

 at the end of this post for some help. Keep an eye out for our Part 4 to this series, 

, for more details on testing all items discussed in this post.

There are users that may not have visual impairments but still have the need for assistive technologies when accessing the web. While a screen reader may not be needed to read the content, a keyboard may be needed to access all of it. Especially for those who have limited interaction, for example, those that cannot use a mouse and rely heavily on their keyboard. This is where visual focus comes into play; it’s a way of showing the user which element they have tabbed to and it currently selected.

If I use the tab on my keyboard, does it go to each new section in a logical order?

When it tabs to that next section is it visibly clear which element is active?

Keeping in line with the Keyboard Access & Visual Focus, all forms should have a logical tabbing order while clearly indicating which field is currently active. Labels should be descriptive to the input you wish to receive, and should have some indication if it is required or not to submit successfully. If a user submits a form with errors, these error messages should be specific to the invalid fields. Avoid using generic messaging (“this field is required,” etc.) in order to help screen readers, and users, pinpoint the issue quickly without having to hunt it down.

Does tabbing through the form go to each input field in a logical order?

Does the visual focus on the element help it stand out as active?

Are the error messages informative to the user?

Okay, in all honesty, this one can be tricky to assess and is best when using a tool to get an accurate reading. After some practice, you’ll be able to see these cases a little better and more quickly. There’s a wide range of potential issues with color on the web and devices. Some users could be color blind, some may have troubles with luminosity, and some may instead have a hard time with colors that are closely related.

For these questions, you do want to answer with 

 means there could be some issues. If your background color and text color are closely related, your users may not be able to easily read through it.

If I squint my eyes and step back from the screen, are there areas that seem like they could blend together?

If I turn the brightness all the way down on my computer/device, are there areas that blend together?

If I turn the brightness all the way up on my computer/device, are there areas that blend together?

Depending on which browser and operating system you’re using, the text may render smaller and could present a larger challenge to read on the screen. Or, maybe it was a smaller font being used to begin with. For this case, the zoom in option works to help eliminate these troubles for the user. The potential issue here is how everything else reacts to the zoom, if it starts breaking other elements then it could work against the user instead of with them.

If I zoom in a few times, does the rest of the site still look usable? For example, the navigation items are all still visible.

When I’m zoomed in, are the other elements of the site maintaining their positioning without overlapping content?

Interactive content is nice to have on a sight, but have you considered that some of your users may be epileptic? What about users that are distracted by moving/blinking content, enough so that they may miss what they came to the site for? Flashing content could trigger a seizure if not used carefully, while blinking content can cause severe distractions. The two are very similar, with blinking being a step down from flashing; anything blinking over 3 times per second would be considered flashing. Either of these can cause troubles for screen readers.

Do I have content that could be considered in this category, and if so, does it have a meaningful purpose?

Is there an option for the user to stop, pause, or decrease frequency for that content?

This one seems pretty easy, right? If you have video on your site, captions should be included for the hearing impaired. For those that are visually impaired, a descriptive transcript should be provided. If you’re video is coming from YouTube, captions may already be provided for you, but you will still want to review them for accuracy.

Do I have multimedia on the site, and if so, am I providing an alternate delivery method for those who may need it?

We have covered this for the most part in the previous sections, as it refers to how the site and content is marked up; similar to laying out a document. You can find more details about this in our 

If I turn off all images and styles, does the page make sense without all of that?

Does the content read in a logical order, or are they out of place?

Can I find the content I’m looking for in a somewhat easy/quick fashion?

Not sure if you’re ready to start assessing yet? No worries! There are a lot of tools out there that you can use to help with assessing your website. Some are a little better than others, and more are being developed. Below are some of the ones I’ve tried out and have kept in my toolbox for future use – all are Chrome extensions – but feel free to explore what else is out there!

Website Accessibility: Assessing your Accessibility (Part 2 of 4)

Accessibility for the web (or any digital content) is a complex topic for content creators, marketers and anyone with something to say online. There are a handful of accepted standards and practices, but nothing official. There is no law yet there has been legal action against organizations for failing to provide access to those who use assistive technology. 

Never fear… it’s not as fuzzy or insurmountable as it may seem 

 in our humble opinion, if you address some basic accessibility issues on your site, you will uncover and resolve user experience (UX) issues that all of your users are likely experiencing. All while making your site more interesting to search engines and doing right by those who need assistive technology to access the web.

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

“Accessibility,” in website terms, is ensuring that those with physical impairments can reach, navigate and access your content. Generally, this means being:

Able to be read by a screen-reader or other assistive technology (magnification or high-contrast color schemes)

In short: “Can people using assistive technologies (AT) such as screen readers for the blind, screen magnification or high-contrast themes get to, navigate through, read your content and use your site’s features?”

content that is accessible by those using AT is almost certainly content that is easily accessible by the general public. I like to say that issues encountered by people using AT are like viewing your site under a microscope. If there is a problem, it will be magnified for them.

Stoll Keenon Ogden give you the real talk about accessibility and litigation

“The United States Department of Justice (DOJ) and numerous courts have determined that the 

ADA requires businesses to make their websites accessible to disabled persons

. This development has spurred significant litigation and, in some instances, resulted in 

, a landmark 1990 piece of legislation that, among other things, “prohibits discrimination on the basis of disability in ‘places of public accommodation,’ ”

While the Department of Justice (DOJ) has not formally issued rules that govern websites, they and other courts have determined that the ADA does extend to websites and other digital content.

Legal action has been taken in the form of “demand letters” that request changes to the website as well as payment of attorneys fees – both of which can be costly.

This is a bit of a grey area as the ADA does not specifically provide guidelines for digital accessibility. However, the World Wide Web Consortium (W3C) and the United States governmental General Services Administration (GSA) have each devised a comprehensive set of standards that have become widely accepted:

W3C Web Content Accessibility Guidelines (WCAG)

Thankfully, there are a handful of very good automated testing tools that can review your site against these guidelines:

Accessibility Developer Tools (Chrome Extension)

Color Contrast Analyzer (Chrome Extension)

Accessibility

A Brief Overview of WCAG 2.1

Website Accessibility: Testing (Part 4 of 4)

Website Accessibility: How to Fix It? (Part 3 of 4)

Website Accessibility: Assessing your Accessibility (Part 2 of 4)

Website Accessibility: An ongoing series (Part 1 of 4)