Web accessibility from the very beginning

The building analogy


Imagine a construction of a big office building. When the project is finished and opened with a grand celebration, new companies move in. After 2 years, one of the tenants decides to employ a few disabled workers. But the space is not adopted for this at all. Doors are too narrow for wheelchairs and there is only one way to move between the floors - and that is by the stairs. The original architect is called to design some adjustments. Then the construction crew moves in for quite a few days. Building is shaking when a pneumatic hammer is ripping the wall. An argument about who should pay for this mess begins between the company and the landlord - the office is indeed a semi-public space so it should be built in a proper way from the very beginning: company workers may not be handicapped, but sometimes there are customers or family members that can not enter the building and are forced to wait in the parking lot, feeling quite bad about it.


How does this translate to web development?


Now, imagine a website that is designed, developed and published. Then the site owner is asking to make few adjustments so that it can be accessible according to new web accessibility standards. To change a web page should of course be much easier than to reconstruct the building, isn't it?… Well, I have a different opinion. When a website is finished and it's not a very big ongoing project, usually developers who were working on it, are shifted to some other projects. And the longer the period of time that passes, the harder it is to introduce the needed changes. For example, original developers change the company and the new ones must be introduced to the project that can sometimes be quite complex. So it takes a long time until he or she installs a local version of the project and gets to know where everything is configured. Moreover, it is often a case that the HTML of the homepage is built from many different template chunks, residing in dozens of project source files and processed by scripts made in different technologies.  


Universal design


For many years now, in the public space design realm, there is a notion called Universal Design. The idea is to include all people with all possible disabilities: visual, motor, mental etc. For example, flower beds at a park can be raised to different heights to be more available for people physically impaired and all information boards can have additional braille prints. Realising the problem and designing a solution from the very beginning is simply much cheaper and much more effective than doing this later.  Now the question is - do websites belong to the public space? 


The answer is usually “yes!”, in my opinion. Unless you hide some part of the website using special access rights and authentication, you want your page to be read by as many people as possible. Of course, sometimes your focus may be on your target group, but you never know what kind of limitation can be the reality of your potential customer. Or maybe you can get a new client only because you created an accessible offer while your competition failed to do so. By the way: the approach in which you are focused on high quality from the very beginning is also in accordance with the First Time Right rule in Six Sigma method.


How to achieve best results


Firstly, the project owner or investor has to be aware of the requirements and advantages of this approach. Secondly, the designer and developers, especially front-end developers, need to have knowledge and experience with creation of accessible websites. The ideal situation is when all project features can be tested by disabled testers. What’s more, also editors should be trained in a creation of accessible content. In short, I would see the process in the following way (having 5 main elements):  


  1. Agreement on standards 

The customer and the contractor have to agree on what standards should be met and on what level (for example WCAG 2.1, level AA). 


  1. Graphic design 

Design is made with accessibility in mind - the focus is on proper contrast and typography (text spacing and font size among others). It is important that the links are distinguishable.


  1. Front-end development 

Elements and widgets are developed according to the WCAG. If the content is dynamic and rich, then also WAI-ARIA should be met.. 


  1. Creation of accessible content by editors

Here we can stress on proper structure of the document - it should have headers and paragraphs. Different content elements such as lists, citations, tables, links, and images should also be used to help make the document more readable for the users.


  1. Accessibility tests and analysis with tools and real users 

Tests and analysis are usually on the client’s side but should also take place in early and later stages of the development. (old text: This should be made on the candidate of the final product, but also on earlier stages and later system maintenance.)


Public institutions


For public institutions in the EU, there is a directive stating that they have to be accessible. In Denmark, more details are included in a special act (“Law on the accessibility of public bodies' websites and mobile applications”) that says when and what standards should be met. More details can be found on the Danish Digitization Agency website. Public institutions’ sites in Denmark also need to include an accessibility statement, according to this information. According to EU regulations you may also add:


  • A feedback mechanism on your website so people can report content that is not accessible.
  •  An enforcement procedure for cases when requirements are not met.




Is making a website accessible a challenge? Yes, sometimes it might, we can agree. But it is an effort that is worth going an extra mile. If you need assistance with this, please read our offer and contact us.


Further readings: