As a frontend developer and accessibility expert, I often run into the same issues over and over again. In a series of blog posts, I will address some of these issues, and I will start with perhaps the most basic one: not adhering to HTML coding standards. This of course includes an endless array of possible mistakes, but I will address some of the most common ones.

Outline

• Introduction
• Using correct heading levels, h1-h6
• If it looks like a button, it should be a button
• Getting too creative with form elements

Introduction

Using correct HTML according to best practices communicates not only the content, but the structure of the content, and what to expect from interaction with it. Assistive technologies like screenreaders will know how to present content in a way that makes sense, and can be interacted with in standardized ways.

As a web developer, you have many opportunities to get creative with markup. And oftentimes, standard HTML elements simply don’t look the way your design does, so it’s tempting to create custom components. This isn’t necessarily wrong, but it’s important to know:

Using standard html patterns increase the chances of your website working smoothly for all users.

And no, this doesn’t mean your website will have to look boring and ugly! You can always start with standard html and add elements for styling, as I will get back to below. Learn how, instead of reinventing the wheel!

Another important thing to know is that automated tools are great at validating HTML syntax, but not at determining if HTML elements are used correctly. Automated accessibility checkers miss many of the most common markup errors, because they have no way of knowing for instance if a certain p element should have been a h3, or if your custom components work the way their appearance suggests.

Let’s have a look at a few of the most common markup issues:

Using correct heading levels, h1-h6

One of the most important ways to structure content is by using heading elements. Non-sighted users often have the heading structure read to them as their first overview of the content. This is only possible if the correct elements are used.

Some of the common mistakes regarding headings:

• Not using heading elements, just styling text tags to look like headings.
• Skipping heading levels, for example using h3 below h1.
• Having multiple h1 headings – the h1 should typically contain the one, main heading for the current page.
• Using a lower heading level because the correct one “looks too big”.

So: make sure your heading structure makes sense! To get an overview of your page, either use a screenreader or any other tool that can give you the page outline. I use the Chrome extension HeadingsMap.

And do avoid tricking editors into using the wrong heading level just because the default styling looks wrong. Make sure the heading levels look good in the authoring tool as well as on the page. If a h3 needs to be smaller or bigger in a certain context, it’s perfectly fine to have different styles for the same heading level as long as it’s done consistently. So do provide heading style variations rather than tempt the editor change the heading level just to achieve a font size difference!

If it looks like a button, it should be a button

A button is typically used to submit a form or execute some JavaScript, while a link takes you to a different page.

Example button:

<button type="button" 
        onClick="alert('I am a button!')">
            Give me an alert!
</button>

Give me an alert!

Example link:

<a href="http://a11yblog.42web.io">Check out my blog!</a>

Check out my blog!

This may seem simple enough, but it’s often hard to distinguish buttons from links visually on webpages, in many cases because it’s tempting to style CTA links as buttons to make them more visible. Avoid if possible, but the most important thing is that the markup is correct. That is, if you need a link to look more like a button, don’t actually code it as a button just for visual effect.

Getting too creative with form elements like radio buttons, checkboxes and dropdowns

“It’s impossible to style form elements, so we’ll just implement our own!”

Chances are you’ve heard someone say the above, or some variation of it. However, support for styling form elements is improving, and there are good and bad ways to do workarounds for when you just can’t achieve what you need. Make sure you know what you are doing, as unusable forms often have dire consequences for a website!

Always use standard form elements, even when you need them to look completely different from their default appearance!

Some common ways of styling form elements:

1. Removing the default styling with appearance: none, and apply your own look. See examples at Styling form controls @ web.dev.
2. Applying your preferred color with accent-color. See accent-color @web.dev.

Also, keep an eye out for the upcoming new ways of styling the select control: more info at the Chrome for Developers Blog.

---

That will be all for now. Stay tuned for more posts on common mistakes regarding web accessibility, and do contact me if you’d like to join this blog!