A picture of Krzysiek

How to make your website accessible for everyone

Our view on accessibility

At Kiwee we’ve decided to check if we comply with major accessibility standards. It turned out that our website needs improvement in several areas. We have refactored Kiwee.eu together with Maciej and Serge and are happy to share with you the results of our first accessibility check as well as some practical tips on what you could implement yourself too.

What is web accessibility?

Web accessibility means that anyone, regardless of their health and condition, can fully access and interact with the web. That includes navigating the website, understanding the content of the website, and being able to contribute - fill and send forms.

I highly recommend watching this introduction to web accessibility from W3 as it shows many situations that we may have never thought of.

Why should you care about it?

Nowadays, Internet became indispensable to us. It is widely used in all areas of life including education, healthcare, commerce and many more. It is essential to provide everyone equal access to this medium. It can also be easier for people with special needs to shop online rather than going to a physical store, provided that this online shop is developed with accessibility in mind.

According to the World Health Organization there are more than a billion people in the world with some kind of special needs. This is about 15% of global population. Making your website more accessible will benefit everyone -- not only people with disabilities, but also people under different temporary conditions: reading in bright sunlight, navigating websites using keyboard with one hand and so on.

And finally, the most important one - empathy. Check how your favourite websites look like to colour blind people. Try to do some of your everyday online routines using a screen reader. If it’s hard, this is the best reason to care about web accessibility.

Take a look at accessibility standards

Definition of accessibility given above is rather general, it doesn’t say too much about how to develop a website in order for it to be accessible. If you want to have some guidelines and technical specification on web accessibility you should take a look at WCAG. WCAG (Web Content Accessibility Guidelines) is a part of W3C and is an internationally accepted standard for web accessibility. It is divided into three conformance levels: A, AA and AAA. The higher the level, the more demanding criteria it contains. ‘A’ is the minimum level of accessibility that should be met by all websites and apps.

When developing a website it is good to keep in mind the four principles of accessibility (POUR). A website should be:

  1. Perceivable - content can’t be invisible to all senses of a user.
  2. Operable - the user interface components cannot require actions that the user cannot perform.
  3. Understandable - the user interface cannot be beyond user understanding.
  4. Robust - the user should be able to access the website using different user agents and assistive technologies.

How we’ve tested our website

The best way to check if your website is accessible is to test it yourself. First, we opened different screen readers and spent some time just navigating around our kiwee.eu website. You will probably quickly discover a lot of issues that prevent you from using the site properly. Of of the nice things to try is accessing the website through a text browser like Lynx. Using it, we often were able to notice that there are some elements that shouldn’t be rendered. Remember that everything that appears in a text browser reflects your website’s HTML markup. For example, in our case, images without alt text appeared as [IMG] tags. Obviously, these tags can be very confusing for people with disabilities. So, what to do?

Things we’ve checked on our website first

After assessing accessibility of our website, it turned out that there are a few problems that were common to the whole website, and some of them would appear only in particular situations. Below we’ve listed the steps that we have taken.

Images alternative text

This is probably the easiest thing to check and to fix. But it doesn't mean it is not important. Obviously screen readers cannot describe you the image. You have to provide the description yourself. It should be precise, not too long (one sentence is enough). My advice for everyone is to always try and  puting yourselves in a situation when you cannot see the image, and you want to know what the image shows.

Remember that alternative text should not be like: “An Image of ...” or “An Image shows ...”. Screen readers always inform a user that the content is an image so it would be redundant. A good idea would be to end every alt text with a period so that the text reader will make a pause after it, making the reading experience more pleasant for the user.

Two dogs playing together in the grass.

Good alt text: <img src="dogs.png" alt="Two dogs playing together in the grass.">
Bad alt text: <img src="dogs.png" alt="Image of dogs">

Decorative elements

It’s recommended that  you provide alternative text to all images. But sometimes there are exceptions to this rule.

Not all of the images should be visible to screen readers. Some images are only decorative, they don’t add any content to the website. Example: a company logo with adjacent name of this company. We don’t need to repeat the name or say there is a logo. Instead, we decided to implement those type of images in CSS using ::before or ::after pseudo elements.

It can be done the following way:

.company-name::before {
    background-image: url('path/to/icon.png');
    background-size: 30px 30px;
    width: 30px;
    height: 30px;
    content: '';
    background-repeat: no-repeat;

This way, the company logo will be rendered just before the .company-name but it will not be visible for screen readers and neither for text browsers.

The downside of this approach is that the image source needs to be specified in the code together with image size. This is not a big problem if you know that a given image won’t be changed soon, but if otherwise, you can try a different method. For example, you can implement the image in the background-image property of some element related to it. In result, you will still have the possibility to edit the image outside of the code (e.g. admin panel).


One of the greatest things about the internet is that everyone can contribute: leave comments, write posts, submit surveys etc. But to make these actions possible for everyone, you have to make sure that every input field has a label associated with it. This way, the screen reader will always know which input field is connected with a given label, and users will be able to make an input.

On our website we’ve done it the following way:

   Last Name
   <input type="text" name="lastname" />

But you can also specify the ‘id’ and ‘for’ properties:

<label for="lastname">Last Name</label>
<input type="text" id="lastname" />

Both methods are correct according to W3C standards. I prefer the first one as I don’t need to remember about giving every input field a unique ID.

Make sure all the form elements are logically ordered and you provide all the necessary information about the required fields for people using screen readers.

it’s good to verify whether users are  able to fill the form as well as send it and receive errors if some occurred, no matter if they use keyboard, a screen reader or just a mouse.

HTML Structure

Another tip is to make sure you take care of HTML semantics. We’ve noticed some issues of this kind on kiwee.eu too. Firstly, the incorrect order of headings on some pages. It’s important because screen readers use them to navigate around the website. Secondly, the syntax highlighting plugin we were using relied on tables for layout, which was terrible in terms of accessibility. When the screen reader hit the code highlighted with the old tool, it read all the line numbers first, and then all lines of code from the top to the bottom. We have changed the plugin to one that has a proper HTML markup. When posting code snippets to your website use <code> for inline code and <pre><code> for blocks of code.

Remember that HTML tags should always reflect the content they convey. One of the common mistakes is to implement buttons as a <div>. Instead you should use <button> element which is designed for this. Make use of various HTML elements like <nav> or <article> to make the layout easier to understand, not only for screen readers, but also for search engines.

Obviously we didn’t manage to fix all the issues with accessibility on our website as it is very broad topic and there is always a room for improvement. Below you will find a few things that we plan to implement in the future and you could also look into that.


Design of your website has huge impact on its accessibility. Pay special attention to colors and contrast. There are many tools that could help you check this:

https://color.a11y.com/ here you can check the contrast

https://toptal.com/­designers/colorfilter/ here you can look at your website from color blind person perspective.

According to WCAG 2.0, contrast on your page should be at least 4.5:1 for normal text and 3:1 for large text. Not only will it help people affected by color blindness or low vision, but  everyone who views your website in different lighting conditions (like strong sunlight).

Ensure that you are not using color alone to provide information. You don’t have to completely abandon the use of colors, just add some extra identification that will be visible for colorblind people (e.g. add asterisk on required form fields instead of only red color).

Provide a way to skip repetitive elements

If you spend some time on the web using a screen reader, you will probably notice how annoying can it be. It always starts reading from the top to the bottom, so when there is a navigation bar at the top of the website (which is pretty common) then you have to listen to all the tab names over and over again. In order to make life a little bit easier for people using screen readers or those who are navigating using keyboard only, you can implement a ‘Skip to content’ button. The most popular practice is to place the button off the screen on page load, and then shift it to the top-left corner as user hits the tab.

.skip {
    position: absolute;
    translateX: -100%;
    height: 1px;
    width: 1px;
    text-align: left;
    overflow: hidden;
a.skip:hover {
    left: 0; 
    top: 0;
    width: auto; 
    height: auto; 
    overflow: visible; 

This will place the link off screen so that it won’t be visible. For keyboard-only users the link will appear in the top left corner after the first tab hit thanks to :focus selector.


Thanks to the internet, access to information and knowledge is now easier than ever. Blind people no longer need inconvenient braille printouts. People with motor disabilities can buy things from home. Deaf people can watch videos with captions. People struggling with temporary conditions (e.g. bright sunlight, arm injury) can access the web. The only thing we need to do is to have some accessibility principles in mind during website development. We can really make Internet a much more friendly place at a low cost. Web accessibility, essential for some, useful for all.



Krzysiek Kaszanek

Full Stack Developer