Top 5 Most Overlooked Accessibility Issues

Accessibility is quickly becoming one of the most important aspects of the way we use the web, if not the most important. Just between 2017 and 2018, the number of federal court cases regarding web accessibility nearly tripled, signifying the trend of accessibility becoming more and more important to users. In response, it will have to be important to website owners as well.

With all this in mind, it’s hard to believe that over 98% of sites on the web are inaccessible according to the WCAG (Web Content Accessibility Guidelines). The WCAG is the source of truth for web accessibility and it is the standard that the defendants are held to in almost all web accessibility court cases.

So after all this why are there still so many inaccessible websites? Perhaps because it’s easier to not put in the time and resources necessary to understand the proper guidelines for accessibility. And when web developers and designers don’t take accessibility into account in their work, it becomes very easy to create mistakes that are overlooked. In this article we’ll go over five of the most overlooked accessibility issues on the web and how to resolve them:

• Insufficient Color Contrast
• Heading Level Order
• Missing Alt Text/Link Text
• No Keyboard Focus Indicator
• No Skip Links

Insufficient Color Contrast

Problem Statement

It should come as no surprise to see color contrast on this list, as it is one of the most common accessibility issues out there on the web. Insufficient color contrast occurs when there is not enough of a visual distinction between the color the text on a page and its background, making it difficult for users to read the text.

Affected Users

Insufficient color contrast poses a huge issue for low-vision users who will likely not be able to perceive your content, but depending on the severity it could even be illegible to someone with perfect vision as well. Having proper color contrast provides a better viewing experience not only for your low-vision users, but for all of your sighted users as a whole.

Legal Risks

Color contrast can pose a definite legal risk to your company if your website fails to meet color contrast standards. The WCAG 2.1 spec states that for AA compliance (the level of compliance used in most web accessibility court cases) you need to have a contrast ratio of at least 4.5:1 for any text or pictures of text; for large text it needs to be a ratio of at least 3:1 (Success Criterion 1.4.3 Contrast (Minimum)).

Solution

The solution is to first audit your site using a tool like axe and identify all of the areas on your website that have insufficient color contrast. From there you can adjust your text colors and/or your background colors to achieve the proper contrast.

Heading Level Order

Problem Statement

Having your semantic headings out of order in the DOM can pose issues for many of your users. Some web designers and developers may not think twice about using an h3 element directly underneath an h1. This may not seem like a minor issue at first, but it can get much worse if random heading levels are thrown around the page without thought. This is particularly important for screen reader users because if they want to navigate the page by specific heading levels the page’s headings have to be laid in the correct order for it to make sense to the screen reader users.

Affected Users

Having a proper heading level order in the DOM is specifically helpful for blind users who utilize screen readers. But you must keep in mind, that to help all of our users, it is far more important to have a heading order that makes sense. Because without that, then none of your users will understand your headings.

Legal Risks

The semantic heading level order is not a requirement in the WCAG, which is one of the reasons that it can be a very easily overlooked issue. Unless your headings are so out of order that your users can’t understand the order on your site, then heading level order shouldn’t pose any legal risks.

Solution

The solution is to make sure your page’s first heading should always be an h1 tag and it should only be followed by the heading level that is next in the hierarchy. The same goes for each tag that follows, they can only be followed by a heading with no more than 1 level of difference.

If it would be too much work to completely redesign your app based on the text sizes you’re getting from the heading tags, one simple way of fixing this issue is to use the aria-level property of your heading tags. The property takes a string containing a number corresponding to the respective heading tag that you want it to be in the DOM. Consider the following heading tag:

<h3 aria-level=”2”>

This heading would have the visual styles of an h3 tag, but in the DOM and when read by screen readers it would be an h2 tag. Of course, doing this would only solve the issue if your headings already were in a logical order, and you just weren’t using the right tags. If your headings are not in a logical order, your best course of action is to reorganize them in a way that makes sense in the heading level hierarchy.

Missing Alt Text/Link Text

Problem Statement

Missing alt text and link text issues are probably some of the most egregious web accessibility violations out there. Alt text is what enables images to be interpreted as text. When you neglect to add useful alt text to your images you are leaving your blind and low-vision users completely in the dark about what you are trying to show your audience. Missing link text can be even worse, especially if the link performs an essential function on your site. If a non-sighted keyboard needed to perform an action on your site and the link for that action had no text associated with it, it would be nearly impossible.

Affected Users

Missing alt text and link text have a profound negative effect on blind users who use a screen reader to navigate the web. Many screen reader users like to navigate the site by a list of its links. If the links are missing text, then they provide no information to the user regarding where they will take the user to. Plus every image on site without alt text is completely useless to them.

Legal Risks

Having missing alt text and/or link text can be a huge legal risk if left unchecked. The very first guideline of the WCAG spec states that all non-text content must have some sort of text alternative (Success Criterion 1.1.1 Non-text Content). This covers images and links among many other things. Another thing to note is that if your website allows your users to generate their own content to post on your site, then according to ATAG (Authoring Tool Accessibility Guidelines) you are responsible for making sure that the content they generate conforms to the WCAG guidelines as well.

Solution

For alt text, you need to be making sure that every single image on your site has alt text, and not just any random alt text. Having an image with bad alt text is just as useless as not having any. Sometimes if it’s bad enough, alt text can be detrimental to the user’s experience. It is important that an image’s alt text be descriptive without being too long. To learn more about writing good alt text, check out this article by Amy Leak: https://medium.com/@amyalexandraleak/should-you-use-alt-text-or-a-caption-48311e259ded

For link text, there may be times where the link itself won’t have any text inside of it. In those cases you can use the aria-label and aria-labelledby to give your links a proper text-based alternative. Using the aria-label property on an anchor tag will allow you to pass a string that will be the label read by the screen reader for the link. The aria-labelledby property allows you to pass a string containing the IDs of the elements that have the text you want to use as a label for the link.

No Keyboard Focus Indicator

.class-name:focus {
  outline: 3px solid orange
}

Problem Statement

Another issue that can make website navigation nearly impossible for an entire group of your users is having no keyboard focus indicator. When a user tries to tab through your site using their keyboard and they find that your site has no focus indicators, they won’t be able to find where they are on your page.

Affected Users

For sighted keyboard users, such as people with low motor skills or people who have an injury that prevents the use of their limbs, the focus indicator is the only thing telling them where they are on the page. This makes your site unusable for these users.

Legal Risks

Having no focus indicators on your site can pose a legal risk to your company. The WCAG states that any interface on your site that can be accessed by a keyboard must have some mode of operation where it has a visible focus indicator (Success Criterion 2.4.7 Focus Visible).

Solution

For a website owner who’s not well versed in accessibility, it may not occur to them to tab through their website to see what happens. This is actually a very important step to testing the accessibility of your website. It’s important to try navigating your site with just a keyboard and make sure that you can perform all the same actions any user would need to on your site. If you find that you can’t perform those actions, then measures definitely need to be taken to improve your site’s keyboard accessibility. Doing this simple test will help you identify many other accessibility issues across your site as well, such as keyboard traps, or tab orders that don’t make sense. Once you have determined whether or not your site is missing focus indicators, you can take the necessary measures to add them where need be.

No Skip Links

Problem Statement

One of my favorite accessibility trends in modern websites is the inclusion of skip links. When a user comes to your site, the first thing at the top of the page is most likely not the main content of the page. Usually there’s a header with some navigation and a list of links to the rest of the pages on the site. For a user trying to access your site from only a keyboard, they would have to tab through all of those links before they could get to their intended target. Skip links allow your users to bypass the parts of your website they would have to tab through to get to their intended content.

Affected Users

Skip links generally have the biggest effect on keyboard users, both sighted and non-sighted. For these users the only way they can navigate through the page is by tabbing through it, or using by using a screen reader’s software to move your focus to a specific area of the screen. Adding a skip link would save our keyboard users the trouble of having to tab through navigation or having to access the deeper features of their screen reader to get to where they want to go. It would be as simple as clicking the link at the top of the page.

Legal Risks

Skip links aren’t required by the WCAG, so they won’t pose any legal risk to your site if you don’t include one. Because of this many website owners might not feel the need to add one to/’ their site, but the benefit they provide to your keyboard users can be incredibly valuable. This is especially true if your navigation contains a large number of links that would make tabbing through them all painstaking.

Solution

With skip links, you are able to put a “Skip Navigation” or Skip to Main Content” button at the top of your page that, when clicked, will send the user’s keyboard focus to the top of the main content area, or to the first focusable element inside it. There are several different ways of building skip links, but I won’t be going over every way to build one. There are plenty of articles out there that can help you build a skip link for your own site, such as this one: https://axesslab.com/skip-links/

Conclusion

As accessibility becomes increasingly important in the World Wide Web today, we as web developers and designers need to start taking measures to reflect these changes. The best thing we can do to help the accessibility of our sites is to keep ourselves educated on the current state of affairs in accessibility and making sure that we know and use what’s in the WCAG. If all website owners took the time to fix these 5 things in all of their sites, then the Web would be a much more accessible place today.

Accessibility in JavaScript Applications

I recently watched an excellent lecture by Marcy Sutton on accessibility in JavaScript applications on Frontend Masters.

Marcy Sutton is currently the Lead Software Developer at Gatsby (one of my favorite tools for building fast modern web apps) and she has been a professional in accessibility for quite some time. She was a Developer Advocate on the axe-core team and she was an Accessibility Engineer at Adobe.

Her lecture takes you through the many different ways that accessibility affects the work we do as JavaScript developers, such as the importance of testing and how to build accessible components. In this talk, Marcy provides a number of resources and tools that developers need to create modern accessible solutions.

In fact, Marcy’s lecture covers so many topics that it would be a disservice to her for me to try and go over all of them in this article. Instead, I will go over five of the biggest takeaways that I received from this lecture, and how each of them can help designers and developers create more accessible products.

Accessibility Debugging

The first topic I’m going to go over is debugging accessibility in our applications. As web developers, it is our responsibility to make sure that the code we’re shipping is accessible to all of its users, and as part of that responsibility we should be taking the time to debug and audit the products we build. There are several web extensions that can do much of this auditing for us automatically, such as axe. But automated tools like this can only do so much.

To truly test the accessibility of your website, you need to test your application by hand. Render your application in a browser and try to navigate your site using only a keyboard. Make sure that you’re able to perform the same necessary actions that your users would. If you find yourself unable to access a portion of your site, or if your focus becomes trapped in a section of the page that you can’t navigate away from, that can be a significant issue for many of your users. A large number of your users will be accessing your site the same way, so it is imperative that they can perform all of the same actions that a user with a mouse could.

The same goes for your blind and low-vision users. Low-vision users face a number of accessibility issues on the web. To ensure that your site is accessible to these users, try magnifying your browser window to at least 200% and see if your site is still usable. Do you have to scroll horizontally to navigate through the entire page? That can be less that ideal for many low-vision users, making a what can be a simple task significantly more difficult. For blind users, it is important that you test your site with a screen reader, and make sure all of the content on your site is perceivable through it.

Screen readers can have a definite learning curve, so it helps to have some screen reader command cheat sheets handy, which Marcy also provides in her course along with a large number of other accessibility resources: https://dequeuniversity.com/screenreaders/

Using Proper Semantic Elements

The proper use of semantic HTML elements is something that Marcy stresses repeatedly throughout her course, and for good reason. In her course Marcy demonstrates that it takes several lines of code to achieve what could be done by using a simple <button /> tag. It becomes much easier to forget to include the basic accessibility features these HTML tags provide when trying to create your own custom versions of them. You don’t want your applications to be “div soup” as Marcy puts it.

Another one of the baked in benefits of some semantic HTML elements is that they already have ARIA landmark roles defined in them by default. ARIA landmarks provide roles to certain sections of your code like banner, main, navigation, form, etc. and screen readers are able to navigate pages by these landmarks and bring up lists of each landmark. Having these landmarks on a page provides a huge benefit to your screen reader users.

To get a detailed description on what elements have ARIA landmark roles and which ones they have, check out this page on the W3C website: https://www.w3.org/TR/wai-aria-practices/examples/landmarks/HTML5.html

Focus Management

Part of Marcy’s course covers focus management, and how to send focus to different parts of your app when the user needs to be alerted to new content. This topic is of utmost importance to keyboard only users and screen reader users. The way that these users interact with the web is entirely from the keyboard, so if there’s something wrong with the focus management, then it significantly detracts from their experience on your site.

Another aspect of focus management is making sure that there is a visible focus indication on each of your focusable elements in your site. This is extremely important for sighted keyboard users because the visible focus indication is their only way of telling where they are on a page. Without a visible focus indicator, the site they’re using might as well be useless.

Utilizing focus management can also allow you to greatly enhance the user experience of your app. It allows you to build skip links that enable keyboard users to skip the navigation options and move the focus directly to the main content. You can create interactions that allow you to move focus directly to new content when the user triggers them, such as automatically sending the focus to the first list element in a dropdown when you open it.

These are both things that Marcy shows you how to build in detail using React, so definitely check it out if you have the chance. If we all develop with accessibility and focus management in mind, we can all build much more accessible and usable components.

Automated Testing

One of the biggest takeaways I got out of this course was the importance of automated testing. Testing can add a huge level of confidence to your code, and prevent you breaking aspects of your app that you would have otherwise missed. There are different kinds of automated testing:

Unit Testing

Unit testing allows you to test the functionality of your components on their own. This is for when you want to test how a component works in isolation, without any calls to an API or rendering the whole app. Jest is a fantastic tool for writing tests in JavaScript, and along with the all of the helpful utilities provided by Testing Libraries, they make it a breeze to query the DOM and make assertions for your components’ tests.

Integration and End to End Testing

There’s a lot of debate around what the actual difference between them are, but Kent C Dodd’s describe’s end to end tests as “a helper robot that behaves like a user to click around the app and verify that it functions correctly” while integration tests “verify that several units work together in harmony”. Check out his article, Static vs Unit vs Integration vs E2E Testing for Frontend Apps, if you want to learn more. These tests can be written in Cypress, which has quickly become the favorite tool of integration testers since it arrival in the JavaScript testing scene.

The Takeaway

However, the biggest takeaway from automated testing is not how to write them — it’s the why. The biggest reason why you should be writing tests is the confidence that it gives you. And once you start testing with your accessibility patterns in mind, it opens up a huge number of possibilities that allow you to ensure the accessibility of your application, and increase your confidence in your product even further.

Manual Testing

User testing is the most valuable way to get data on the usability of your app, especially when accessibility is concerned.

Marcy makes a point in her course at the end of the testing section, that despite all of the great things automated testing can do for us, it can’t do everything. We still need to do more to make sure that our sites are fully accessible and usable.

Manual testing includes some of the accessibility debugging steps that I mentioned earlier in the article, such as keyboard testing, screen reader testing, and magnification testing. But what I believe is far and away the most useful form of manual testing, is user testing.

User testing is the most valuable way to get data on the usability of your app, especially when accessibility is concerned. We as developers can fiddle around on screen readers with our eyes closed all day long, but none of it will give us as much useful information as an actual user who is blind, testing your app. Many people who are blind use screen readers as a part of their everyday life, so they are much better at using them to navigate our applications than we are. Not only that, but we can only do so much to try to understand the pain points that they experience in applications. And this of course does not only applies to our blind users, but to all of our users. The best way we can truly understand is by allowing our users to tell us themselves during user testing.

Fable is a great example of a company who provides this kind of accessible user testing as a service, be sure to check them out if you are interested in doing some user testing.

Conclusion

Accessibility has been changing the way that we design and develop for the web, and I think that change is good. It is important that we keep up with the accessibility trends and make sure that we’re doing everything we can to make our products as accessible for our users as possible. The world has been changing to be more inclusive to people with disabilities, and it is a welcome one. Making the things we create on the web more inclusive to all users can greatly improve the quality of life for everybody that uses the web.

At the beginning of her course, Marcy describes accessibility as something she can’t turn off in her brain and that she hopes her course flips that switch for her viewers as well. My hope is that each of the takeaways in this article helped you begin to flip that switch in your brain as well, and that you’ll begin to design and develop with accessibility in mind.

Related Links

• https://frontendmasters.com/courses/javascript-accessibility/
• https://marcysutton.com/
• https://www.deque.com/axe/
• https://dequeuniversity.com/screenreaders/
• https://www.w3.org/TR/wai-aria-practices/examples/landmarks/HTML5.html
• https://kentcdodds.com/blog/unit-vs-integration-vs-e2e-tests

This post originally appeared on Medium: https://medium.com/cross-team/accessibility-in-javascript-applications-96a3e02d705

What goes into a blog post? Helpful, industry-specific content that: 1) gives readers a useful takeaway, and 2) shows you’re an industry expert.

Use your company’s blog posts to opine on current industry topics, humanize your company, and show how your products and services can help people.