Your website does not meet accessibility (WCAG) criteria - our developers advise whether to fix the current website or create an entirely new website
Compliance with WCAG (Web Content Accessibility Guidelines) criteria is crucial to creating software solutions. Read more about how accessibility benefits everyone in our previous blog.
According to our accessibility specialist Mari-Ell Mets, from 2019, the obligation to ensure accessibility established by the European Union directive applies to the public sector, which essentially means that websites and mobile applications must meet the AA level of the WCAG 2.1 standard.
From 2025, this obligation will also apply to certain areas of the private sector. You can find a detailed overview of the requirements in the Accessibility Act. Ensuring accessibility is based on four principles: perceptibility, functionality, comprehensibility and reliability, which are divided into criteria, and if fulfilled, a website can achieve the required level (AA). Ensuring accessibility is generally time-consuming, and we recommend to start preparing for the transition now.
Suppose your website does not yet meet the AA level of the WCAG 2.1 standard. In that case, you have two options: either develop an entirely new website that immediately meets the accessibility criteria or update the existing one (front-end facelift). In this article, our developers Mairo Aljaste and Sander Rautam and specialists help you decide which solution is the best for you.
How to start the development process?
It is necessary to decide with the development partner whether it is reasonable to create a new website or adapt the old one to meet the WCAG criteria.
If you want a new website, you must first have the designers prepare a design that meets the UX/UI and WCAG requirements. However, choosing a facelift to bring your existing page into compliance with WCAG requirements, we recommend starting with an audit to identify problematic areas on your website. We recommend analyzing the audit results with the developers to assess your website's WCAG level at the moment and what can and cannot be improved.
There are different levels of WCAG guidelines, and you definitely don't have to do everything at once. In cooperation with the development partner, you can establish the order of priorities and also decide which accessibility tools should be focused on (screen readers, browsers, operating systems, etc.).
Option 1: Improving existing web accessibility
In such a scenario, the website has already complied with accessibility standards to some extent, and you want to supplement or improve the existing solution. This step considers the users and is a much better choice than staying at the previous level. However, this option can be challenging in terms of development and cost. Let's talk more about the pros and cons.
Pros
Thanks to accessibility additions and changes, your circle of web users will probably expand as well. For example, if you previously did not consider visually impaired users on your website, you now want to include a screen reader. Or, if you previously did not consider users who cannot use their hands (temporary or permanent trauma), you now want to add the possibility of using voice commands.
It is important to note that visual impairment is not only a permanent or congenital visual impairment but can affect us all at some point in our lives: temporary eye trauma or disease, as well as the deterioration of vision as we age. According to research, one in 12 men has some form of colour blindness. You can read about using accessible colours in web design in our previous blog post.
Cons
It depends on the web, but often making an existing web accessible tends to be more difficult from a development perspective than developing a new web. Why so? The developer has to "dismantle" the existing code and understand the work of the current components and, based on this, figure out if and how it is possible to add the desired accessibility there. The code is typically written by someone else and is often undocumented.
The project can be very time-consuming - the amount of time depends on how much accessibility support is available on the current web and how difficult it is to "dismantle" the existing code. Also, consider how easy or difficult it is to add new accessibility functionality to the existing website.
The previously conducted audit helps to plan the time consumption, which we discussed at the beginning of the article. Still, when adding to the existing website, unpleasant surprises may also appear that had yet to be planned in the volume estimate. For example, the website is 10-15 years old and outdated and has technical support difficulties.
Some components or code may not work or need to be rewritten to add the new accessibility support features you want. Before starting the development, we ask the customer to provide the already known information about what does not work with the current website to prevent surprises and save time.
As a result of the above, updating an existing website is often more expensive than developing a completely new and immediately accessible website. First, you need to do an audit, and it costs money. Then the cost of the project depends on how complex the web is, how much and what quality of accessibility support is already available on the web, what needs to be added, and how difficult the addition turns out to be.
In all likelihood, updating the front-end alone is not enough to improve the accessibility of the existing web. Still, it is also necessary to change the back-end developments and design. For more complex systems and websites, corresponding changes should be made by the partners with whom the subscriber's website is interfaced. For example, suppose the subscriber's website uses Google Maps or Pipedrive forms as the only solution. In that case, they should also meet accessibility requirements because the subscriber's development partner cannot change them himself.
Examples of projects made by TWN
TWN Web and TWN Blog
At TWN, accessibility has always been close to our hearts. We also offer our clients WCAG audits and web development services according to WCAG criteria. Therefore, our website and blog, which is also our business card, must meet the WCAG criteria.
Visually impaired people use screen readers to navigate the web and read text aloud, and our developer task was to make our website and blog accessible to screen readers. We changed the somewhat complicated structure of our page and the contrast of colours to comply with WCAG criteria and be screen reader friendly.
We also added appropriate notifications for screen readers to inform them of opening and closing menus and accordions. We also introduced additional translations for screen readers (which are not visible to the average user).
A screenshot from Trinidad Wiseman's web shows that when tabbing (with the keyboard), the focused element has a visible contrast focus box. The colours of the text are also in the correct contrast ratio with the background.
In the case of this project, accessibility works were not carried out on the old website, but they were carried out as a separate phase at the end of the project. Since the deadline for the completion of the new website was fast approaching, we decided with the client that once the portal was made public, we would immediately carry out comprehensive WCAG testing separately and then make the appropriate additions and changes.
In addition to the developer and tester, Mari-Ell Mets, our certified web accessibility specialist, participated in the testing and tested with three different screen reader software. We divided the accessibility deficiencies revealed as a result of testing into three groups based on priority and criticality:
- simple typos (about half of them) were quickly fixed - e.g. missing aria labels/titles or wrong title style.
- various topics related to the behaviour of screen readers went under medium priority errors. E.g. one screen reader worked correctly, the other did not, as well as different behaviour in desktop and mobile views.
- high-priority additions (about 10%) included situations where the use of the application was seriously disturbed - for example, the wrong keyboard opened in the mobile view, the links in the menu had the wrong focus order, or under certain conditions, no match was found when using the search function.
Speaking of challenges, solving some medium and high-priority bugs already required a more serious rework of the original solution. In one case, it was impossible to achieve the desired result because the framework used did not allow the implementation of a user-friendly design that would also be accessible. Today, a new web version is already in production, where this framework is no longer used, and thus this particular problem has also been eliminated.
A lesson we learned, and one we often don't think about often, is that if the developer is using a PC, testing the code in development on a Mac screen reader is a real headache. So, think carefully about the equipment used in the project.
Our developer's task is to estimate the amount of work required to change the existing subpages to meet the accessibility criteria. He also finds out the risks, such as can break in the old codes during the addition of new functionalities and how the update can affect the existing web pages. On the other hand, our tester is responsible for ensuring the accessibility of new developments daily.
Option 2: development of a new accessible web
In this scenario, you have a website, but you want a completely new design that meets WCAG standards, or if you don't have a website at all and want to create it, immediately considering WCAG standards. This may be a better option for development and cost than adapting an existing page to WCAG criteria. Let's talk about the pros and cons.
Pros
Developing a completely new and immediately accessible web is a more straightforward, convenient, and transparent solution for all parties involved. An analysis is done, and all desired accessibility functionalities are already agreed upon in the project's initial phase.
Developers don't have to start dissecting someone else's code (it may be poorly documented or has no documentation) or predicting whether or not the new desired functionality can be added to the old web (often, the reality becomes clear only during the work). When developing a new website from scratch, we can document all the developers' work in high quality and detail so that in the future it is crystal clear what was done.
The new website that complies with accessibility standards immediately considers many different user groups (e.g., in addition to ordinary users, visually impaired users, and users with temporary or permanent trauma).
When developing a new website, it is possible to immediately calculate the time spent and the project's cost to the client.
Cons
It is difficult to develop if there is no preliminary analysis and it is not known exactly what the customer wants. There may be "moments of surprise" when developers test new approaches, functionalities or technologies and how well they support accessibility. Generally, these surprises can be caught already in the design phase.
Examples of projects made by TWN
EAS.ee front page
Haridusportaal
Visittallinn.ee
In conclusion
As we said, in 2025, compliance with accessibility will also apply to websites in certain areas of the private sector (it already applies in the public sector) and the Consumer Protection and Technical Regulatory Authority can come and check your website. The right time to think about the accessibility of your web is now because development activities require planning and time.
We hope that our article gave you food for thought and direction, whether to make the existing web accessible to the requirements or to develop a new one - immediately conforming to the WCAG requirements. We recommend starting with an audit. Once this is done, you can take offers of development volumes for both solutions and then decide. You can get a more optimal offer of development volumes if a new design is already available for the new website.
Try Trinidad Wiseman's accessibility tool here.
