The Most Common Developer Web Accessibility Mistakes & How To Solve Them

#a11y #css #html

Sadly, accessibility is not often given the priority that it should be. It’s harder to make a website accessible at the end of development than during development.

Accessibility is so important and unfortunately, it’s not often seen as a priority in companies unless a client requires it, e.g. for government sites. The fact is that all sites should be inclusive and you could even find yourself facing a large fine if a disabled user is unable to access your services.

The World Wide Web Consortium (W3C) has a set of Web content accessibility guidelines with 3 levels of conformance: A (lowest), AA, and AAA (highest). AAA is quite difficult to achieve, however I’d always recommend aiming for the highest, so then your site should end up at least AA, which is required by most government sites.

It’s also important to note that these guidelines are not just for developers, a lot of consideration needs to be taken at the design stage when choosing colours, font sizes, etc too. Here are a list of things that I’ve noticed come up a lot during development and how you should think about doing them in future. It’s by no means a full list though, so please still familiarise yourself with the guidelines.

Removing focus styles

This is a HUGE mistake that people make. We all know that the default focus styles can really ruin a design, but they are there for a reason. Some users are not about to use a mouse due to disabilities, so they need to use a keyboard to navigate through your site. If you remove these styles then they will not know what action that they are about to perform.

So how can we maintain accessibility and aesthetics? :focus-visible is a pseudo class created, similar to :focus that is meant to solve the issue of focus styles also being visible when a user clicks with a mouse. Sadly it’s not widely available on browsers yet as it’s part of the CSS4 working draft.

I personally use the focus-visible polyfill. I am then able to turn off default focus styles:

{ 
  outline: none;
}

Then I can style every element that requires a focus separately, or all elements using the new .focus-visible class that the polyfill adds. For example:

.focus-visible
{
  outline: 1px solid $brilliant-rose;
}

or styling a specific element:

.top-link{
  border-bottom: 1px solid transparent;

  &.focus-visible
  {
    outline: none;
    border-bottom: 1px solid $brilliant-rose;
  }
}

Not making elements tabbable

It’s all very well styling the focus but we need to make sure that users are actually able to tab to elements that have an action. This is where it’s important to select the correct HTML element to use. Both anchor links and buttons are automatically tabbable, however the button is also triggered using the space bar. The general rule I use is:

Buttons — use when triggering an action on the page, such as a javascript action like opening a menu, or submitting a form
Anchors — use these to take a user to another page or another part of the page

If you use other elements such as a div then you will have to add in both a tabindex attribute AND ensure that the event is called on enter. For example:

<div tabindex="0">Test Element</div>

Would make the element tabbable in the order that it appears in the DOM, but if you have an onClick action then the user will not be able to hit enter. There are multiple ways of doing this, for example if you use React

<div tabindex="0" onKeyPress={keyPress}>Test Element</div>

The even then checks for the enter key

  if (event.key === "Enter") {
    //action here
  } 
}

There are very few scenarios I’ve come across where this would be needed over a button.

One gotcha I’ve recently had come up too is that an anchor without a href value is not tabbable. This was due to a library I used to scroll to another part of the page. You can add in a # as a fix but really you should consider if it’s actually more suited to a button element if it’s only using javascript. There’s no definite answer here.

Having an illogical tab order

Sometimes, especially when using content management systems (CMS), the markup may be added in an usual order. The styling is then done in such a way that it looks fine, but when you tab, the order is incorrect. Really you should always try to put elements in order, but if you are in this situation then you will manually have to use the tabindex attribute to set your order.

Not hiding tabbable elements correctly

Another important thing to remember is that just because an item is hidden from view, it doesn’t always mean that it can’t be tabbed to. This is the case if you are using CSS attributes such as opacity: 0. The element is technically still able to be focused on and this can be really confusing if you’re a keyboard only user. **Make sure that you use display: none or visibility: hidden **which will stop users being able to focus on that element. If this affects an animation then a trick you can use is to apply the style after the animation.

Using icons as buttons

This is something that we see on pretty much every site nowadays. The problem is that a lot of sites are not considering screen readers users as they won’t have a description of this icon. Some people add in a title attribute to links or buttons, but you should not be relying on title attributes for
accessibility. Unfortunately it’s not consistent across devices, browsers and screen reader software. Even aria-label should not be relied upon.

The easiest way is to add in some text that is hidden off the screen and will only be read out by screen readers. There are a few ways to do this, here is one example. Do not use display:none because then it will not be read out either.

{
  clip-path: inset(100%);
  clip: rect(1px 1px 1px 1px); 
  clip: rect(1px, 1px, 1px, 1px);
  height: 1px;
  overflow: hidden;
  position: absolute;
  white-space: nowrap;
  width: 1px;
}

An example of this in use

<button>
  <i class="fa-times"></i>
  <span class="visually-hidden">Close Menu</span>
</button>

I personally have started using inline svg icons over font icons. Inline SVGs can have a and a tag, so if you are able to add those within the SVG then you do not need to add extra text that is visually hidden. The same is the case if you use functional elements, you can use the alt attribute.

One scenario I’ve come across too is that I had a reusable inline SVG that required different descriptions. In this case I used aria-hidden attribute on the SVG element and used the visually hidden text as a description. It’s important not to confuse screen reader users with multiple descriptions.

There is also the case that maybe we should be adding more text for all users. I’ve read a few articles on here suggesting that actually icons alone aren’t very user friendly.

Using unsuitable link text

Imagine that you are a screen reader user and you’re tabbing through a long list of links. “Click here” or “read more” for every link isn’t very informative is it? We need to ensure that link text is descriptive on its own.

There are scenarios where it would look really bad to add long descriptive text. I’ve worked on a site that listed events using a CMS and we had a book tickets link next to each event. It would have really ruined the look of the site to add the whole event description onto the link that was styled like a button.

This is where visually hidden text comes into play again. We can add an extended description for screen reader users without ruining the aesthetics of the site.

<button>
  <span>Book Tickets</span>
  <span class="visually-hidden"> for X event on the DD of MM YYYY</span>
</button>

Make accessibility testing part of your standard testing!

As you can see, these are very simple little things to do at the time of developing, but if you had to go back through a website and add these in, it would take a long time. Make this part of your standard process.

Originally posted on Medium