The topic of web accessibility is huge, and it can be hard to know where to start. In this blogpost I will cover 5 principles that you can, and should, start to implement straight away. I have selected these 5 topics, not because they are more important, but because they should be quite easy for a web developer to add to their existing toolbox.
Prerequesites For this blogpost I will assume that you have some basic knowledge and understanding about web accessibility. If you don't I recommend reading Part 1: Introduction before diving in to this.
If you want the TL;DR (too long, didn't read) version you can jump right to the summary.
1. Use the correct semantic elements
In html we use elements to structure our content. An element concists of two tags, one opening- and one closing tag. Like this:
<div> </div>
Semantic elemetents are elements that represents a logical section of content, and have a clear meaning.
In the example above I used a div element. This is not a semantic element. The div doesn't tell you anything about what kind of content you should expect to find inside it.
One semantic element you've probably used before is the h1 element (or h2 - h6). Maybe you thought it was just a simple way to style all headers consistently? It is actually a way to structure your content.
Elements for overall site structure
The above image illustrates how you can structure your site using semantic elements. This will of course depend on what kind of content you are presenting on your site. For example the upper <nav> could also go inside the header. And there could be an aditional <header> inside a <section>. But I wanted to keep the image simple to give you an overview of how it could look.
<header>
The header element represents introductory content. This typicalle contains the site logo, some links, a search form and maybe the author name.
<nav>
The nav element represents a collection of links which purpose is to be used for navigation. There can be more than one <nav> element on a page. One could represent the site-menu, and another could represent table of contents for the current page. Its important to give them different identifications so its clear for non-visual users what they represent. You can still usa an unordered list to organise your navigation links - but put the whole list inside the <nav> element.
<main>
The main element represents the dominant content of the page.
<aside>
The aside element represents content that is indirectly related to the main content
<section>
The section element represent content that does not have any other tags to represent it. Typically genereic or standalone content.
<article>
The article content represents content that is independent from the rest of the site. If a user was presented this content outside of the webpage it would still make sence.
<footer>
When inside the body the footer element represent the website footer. If it is placed inside an article element it represents the least important information about that article.
Other elements worth noticing
<hr>
It's so easy to throw in a <hr> when you need a nice line on your page. But it's worth noticing that the <hr> tag actually have semantic meaning. It represents a thematic break in the content - and it is anounced by screen readers.
So if you just want a visual horizontal line for decoration, you should not use a <hr>, but use a css border instead.
<button> vs <a>
The button should be used when you want the user to trigger some javascript by clicking on it. While the a-element should be used for links that takes the user to another page.
2. Using color
Contrast
A lot of people have problems with their sight. It could be color-blindness, or other challenges. But either way it is important that we use enough contrast between colors to ensure that the content is clearly visible for all users.
To be WCAG AA compliable the colors you use together should have a contrast ratio of at least 4.5:1 for normal text, and 3:1 for large text. Dont trust your eyes! Even though you think it looks nice, and that the contrast is good enough you should always check.
And don't trust that the designer either. Some designers are up to date about accessibility and WCAG, but theres also some that are not. But if you find that the colors you got from a designer is not WCAG compliable remember to be nice about it.
There are a lot of free tools you can use to see if the contrast is good enough, I like this contrast checker.
Don't use color alone to convey meaning
On the same topic, don't use color alone to convey meaning. As an example links should always be marked with something more than a different color, like an underline. Or if you display an "error"/"success" message that are set to be red/green based on some state you should make sure that the state is still clear for people who can't see the color. You can do this by being explicit in the wording of the message.
3. Always add type to input fields
The HTML type attribute is important for screenreader users. The screenreader will anounce what kind of input type that is expected. Especially important is it to set the type="password" for password input fields. If the type is missing on a password field the screenreader will speak the users password aloud as they enter it.
4. Don't use pixels for font-size
Different browsers will display content a little differently. And it is also possible that your users have browser-extensions that changes the font-family or basic font-size to make it easier for them to read. Thats why WCAG recomends working with proportion and not pixel-sizing. If you use the em unit to set font-size instead of pixels. Em means that the text-size is set relative to the default font-size. (2em means 2 times the size of the default). By using em the text on your page will scale nicely no mather the users default settings.
5. Always add styling for focus-state
If a user is navigating your solution with a keyboard they schould be able yo see where the focus is right away. Focus-style is very often displayed as a border around the conent in focus. Unfortunatley a lot of developers (and designers) tend to remove this because it doesn't look nice. You can of cource style the focus-state however you want, but make sure it is clear enough so the users don't have to wonder where on the page the focus is.
Summary
Lets summarize what you have learned in this blogpost.
- Always use the proper semantic element in html
- Make sure that the colors you use have the proper contrast ratio. And also, don't use color alone to convey meaning.
- Remember to add the type property to input fields. Especially important on password fields.
- Use a relative measurment for font-size. Like the em-unit.
- Make it easy to see where the focus-state on your page is, by always adding styling for :focus.
If you start implementing these five principles right away you are allready on your way to help create a more accessible internet. In the next part of this series I will cover some more complex topics. If you don't want to miss it make sure to follow me on twitter. :)
Resources
- HTML element reference (MDN Web docs)
- HTML seamantic cheat sheet (Learn the web)
- Contrast checker
- Syntax.fm have a podcast episodes where they talk about html semantics
Did you find this article usefull? Follow me on twitter to be notified when I publish something new!
Also, if you have any feedback or questions, please let me know in the comments below. :)
Thank you for reading, and happy coding!
/Eli
Top comments (8)
“The button should be used when you want the user to trigger some javascript by clicking on it. While the a-element should be used for links that takes the user to another page.” <—- I feel like this is often abused. More people should follow this advice 👍🏻
I know the tags names are meaningful but when it comes to real usage they are really hard to use in proper way.
Especially tags like article and section.
Any guidance will be appreciated 🙏.
Lets use this current page on Dev.to as an example. :)
The content of my post could be inside of an
<article>element. Since the content would make sense alone - outside of the dev.to context.But the area for the comments could be inside a
<section>element since they would not make sense on their own (so not an article), and section is a way to group things that does not fit in any of the other semantic elements. This section could be placed inside of the article too - since they make sence together.But the "Read next" component in the bottom could be another
<section>, outside of the article.I try to think that a section is a way of grouping content togeteher. Would it make sence to say "The comment section" and the "Read next section" to explain which part of the page I'm talkin about? If yes - then I use a section. (If there is not a more appropriate element to be used).
Okay that's helpful. Using Dev.to as an example is brilliant 👏
Thank you very much.
I didn't know about this! It makes a lot of sense though, especially considering the table of contents idea!
Glad you found it useful :)
Bookmarked and liked. I try to be mindful with my contrasts but I'm rubbish at semantic elements, hopefully I can refer back to this frequently.
Glad you like it :) When ypu start using them more it will be easier to remember the different semantic elements too :)