Accessibility Dont’s, Learn From Basic Mistakes in Web Design

AccessibilityPosted on

9 min read

Make your next project a little bit more inclusive and usable by not removing or changing some default browser behavior.

When we have to develop a complex system, we have to pay attention to shockingly many things. Just on front-end, we have to choose a proper CSS methodology for a long ride,  optimize our assets and the overall performance, choose a JavaScript framework, and designing in overall.

On top of this, there is accessibility too. Making an accessible site is no easy, but like with many things, we can start it small.

The next five examples are elementary. So simple that we can improve our sites with just a little effort to be more inclusive and less annoying. We can justify these points only by logic, but I will try to refer to a correct source so everybody can read more on the topic.

Confession time: unfortunately, the following five mistakes are something that I made more than I’m proud of. Nowadays, I try to care more about them, but I don’t want to free myself from these mistakes. I think the right thing here is to learn from these common errors and try to give more with our code.

Today the browsers are smart enough to guide us towards inclusion in an essential way. For some reason – and because we are people – we make mistakes. One thing is true about accessibility; it is hard to start. So why not start it with baby steps?

This list is not a complete one; it is far from that. The good thing about it that it is easy, and correcting these errors can make an impact. It is mostly based on my experience.

Don’t Remove the Underlines on the Links

Removing the link underlines is often one of the first steps in our CSS. We declare it globally on the <a> tag. On its own, this is not a problem. The removal can be understandable. The underlined style not the most aesthetic on some UI elements.

a { 
    text-decoration: none;

The main problem here is the global removal. We can’t remove the underlines from the links in the body copy because it can be a real problem for a lot of users. The goal of the link underline – besides that, it is a universal convention – is to give more visual differences besides just the color. If we only use color to convey meaningful information, we exclude our users with color blindness (or, in some cases, low vision problems).

We can use other methods to highlight links, but the underline is the best pattern here. The goal is not to use only color .

Here we talked about a block of texts. We can remove the underline where the surrounding adds unique meaning. If we have a navigation bar (or a section which is clear navigation) in our header section, it is more understandable that it is a menu.

(1) Because it is clear that this is a navigation bar, we don’t need the default underline. (2) In the body copy, we have to highlight the links to make them stand out. Source:


  • Don’t remove the underline from the links in a text context where it is hard to distinguish it.


  • Use underline on every link, no matter where they are, this is the bulletproof method.
  • You can remove the underline if it is self-evident that the element is a link like in a navigation section.

Don’t Remove the Outline From Focusable Elements

I think this is the most famous lousy pattern which is present in a lot of production codebase. In an HTML document, we have interactive elements: links, form elements, buttons that can get focus, which has an outline style by default. This behavior is useful for users who are navigating with the keyboard. They need to see on which element they are on when navigation through a page.

* { 
    outline: none;

Like in the case of the links (in the previous section), here is also true that if you remove it, you have to remake at least the same or a better version. There is a debate that the default outline (handled by the browsers) is the best possible one, but it is still a good basic style.

The outline is mostly useful when we navigate with the keyboard, and the browsers respect this by default settings. If we click on a link using a mouse, we can’t see an outline, but using the tab key, we will. This behavior makes less noise. If we make our own, it will be shown when we use the mouse too.

An improved outline that works without the outline. Source:

It is because of the :focus state currently can’t make a difference well between the sources of focus. Fortunately, there is a new feature named :focus-visible.

To learn more about the importance of the outline, please visit MDN.


  • Don’t use * { outline: none; } at all.


  • Only remove the outline on the element where you don’t need it
  • If you remove the default outline, make a better one. An excellent example of this is the Bootstrap 4 button styling.

Don’t Remove Textarea Resize Functionality

The textarea has a neat feature which is the resize. It enables the user to make it bigger, scale into both axes.

textarea { 
    resize: none;

Sometimes we like to disable this feature and sometimes we have to. A proper middle way can be to limit it to vertical resize and turn off the horizontal. It can still be problematic; hence we restrict the user.

The handlebar for resizing a textarea. Source:

Cătălin Roșu wrote a great article about this topic; I’m sure it worth your time!


  • Don’t remove the resize ability on textarea elements entirely.


  • If you have to remove, create an alternative solution like resize the field when the user hits enter.
  • Remove just the horizontal axis and give the freedom to adjust the height.

Don’t Open New Browser Windows

By using the target attribute on links, we can override the default opening behavior, which is open in the same window (self).

For some reason, I often make this mistake using the _blank value. As I read more and more about accessibility, that is clear to me; this is a bad habit. We make a decision instead of the user, which is always questionable. If the user wants, he/she can open the link in a blank window easily.

<a href="" target="_blank">My link</a>

The main problem with the target=”_blank” opening is that some users will have trouble to navigate back, and we will confuse a lot of them (why a new window opened recently?).

There are situations where we have to open a new window. Usually, when the user has pending work on that page, like filling a form and want to read your privacy policy (which is on a different URL). If we have to use it, the best thing we can do is to notify the user in advance (with text or icon).



  • If you have to use it, use just when you truly need it.
  • Fine-tune it, tell the user what to expect before the click.

Don’t Use Fixed font-size on html/body

It was a standard method to reset our HTML document’s font-size somehow to a new basic. On its own, this is not a bad practice if we use relative units.

There is a lot of reason why (and how) you want to change the default font-size, and this article isn’t about this concern. The pivot here is we should always use a relative unit (eg.: %, em, rem) because we intentionally modify a user setting, which is useful.

In the browsers, you can not just change the overall zoom level (globally, which also affects the fixed values), but you can change only the font-size. We should respect the user’s decision here, too, because, in the end, we can code in a better way to adapt.

Change the default font size in Google Chrome.


  • Don’t use fix font size on your elements.


  • If you want to change the default font-size (on the html/body elements globally), use a relative value.


Designing something is hard. Every decision is different, and nobody has the correct solution to your problem. If you want to make a little bit better web-based projects, you can start it now with these small tips.

Need a web developer? Maybe we can help, get in touch!

Similar Posts

More content in Accessibility category