Accessibility + Quality Assurance

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

By:

Rebekah Beran

on 12/28/2017

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

Part 2: Assessing Your Accessibility (What to Fix) ⬅YOU ARE HERE

Part 3: How to Fix It?

Part 4: Testing

So you’ve heard talks about “Web Accessibility” lately – and maybe you have already read our part 1 to Website Accessibility 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 W3C or Section 508, but let me save you some of that time!

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 no to any of those questions, it is suggested to make improvements to that section.

Content

First up, the Content. 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: Functionality & Styling.

Whether your site’s content is mainly text, images, or a mixture of both, you’ll want to review all of it 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.

Page Titles

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

Headers

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

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?

Link Text

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?

Functionality & Styling

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 Tools at the end of this post for some help. Keep an eye out for our Part 4 to this series, Website Accessibility Testing , for more details on testing all items discussed in this post.

Keyboard Access & Visual Focus

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?

Forms/Labels/Messaging

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?

Contrast Ratio

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 no, as a yes 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?

Resize Text

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?

Moving/Flashing/Blinking 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?

Multimedia Alternatives

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?

Basic Structure

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 Part 3: How to Fix It post.

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

Tools

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!

Share to

Related Posts

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

By:Ben Wilson on 12/14/2017

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.

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

By:Nick Stewart on 1/4/2018

In Part 3 of our ongoing series on Website Accessibility, Nick Stewart gives us a brief lowdown on how to code semantic HTML for current accessibility standards.

Read More »