The topic of web accessibility is huge, and it can be hard to know where to start. In this blogpost I will cover 5 things 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.
For this part 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 blogpost.
Blogposts in this series
Note, the other posts will be published in the next couple of weeks. The links will be updated – if the link is not active it is because the post is not published yet.
- Introduction to accessibility
- 5 accessibility principles you should start implementing right away(this blogpost)
- Looking at some more complex topics
- A closer look at ARIA
- Tools
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.
Screen readers and other assistive technology uses the semantic elements to get information about the content on your site. So an easy way to make sure that you’re creating more accessible websites is to use the correct semantic elements.
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
could also go inside the header. And there could be an aditional inside a . 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
<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 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.
Should I never use div or span?
You can still use div or span, but use them with causion. I have a rule that I try to only use them when I need to create containers for styling purpose only.
And if you absolutley have to use a div for content, add ARIA-roles to make it accessible instead. I will go deeper into ARIA in part 4 of this series.
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 seamntic 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 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
The post A beginners guide to web accessibility for developers. Part two: 5 principles you should start implementing right away first appeared on acupof.dev