The Risks Of Making Inaccessible Websites

The figure represents a battle between an evil PC spewing a chaotic blob of div tags. In contrast, a scroll labeled "EU Law" emanates a stream of proper semantic HTML tags. Two people wearing glasses are observing the scene.

During my years working in IT consulting I once saw a project of a public online store of a mobile phone carrier built entirely using the framework Angular with no Server Side Rendering (SSR). Its SEO (Search Engine Optimization) score ended up being an absolute disaster!

Although Single Page Application (SPA) frameworks like Angular are amazing tools for highly interactive dashboard and web apps, I was genuinely shocked to find out it was used to build a public website, whose crucial functionality is search engine discoverability and indexability. This choice not only severely hampered its SEO but also reflected a broader neglect of fundamental web principles.

Components were often made of generic <div> tags, overlooking critical accessibility features that are built into semantic HTML. They created a website that was not only difficult for search engines to crawl but also inaccessible to users with disabilities.

Such website today would face severe legal and financial consequences, since this type of e-commerce website must now comply with the European Accessibility Act.

NOTE: This article is bit technical, if you are not interested in the coding part, you can go to the section talking about the risks of non-compliance.

The Web Before Javascript Frameworks

The ”web 1.0” was born as a decentralized medium for sharing static HTML documents, connected by the revolutionary concept of hyperlinks. Its elegance lay in its simplicity: retrieve a document, read it, click a link, and retrieve another. This model was robust, accessible, and it worked everywhere, even on extremely low powered devices.

However, over the past decades and with the rise of Javascript frameworks, the web has become slower, heavier and harder to use. A drastic cultural shift affected the industry that encourages new developers to “learn frameworks like React first” before learning the fundamentals of the web such as HTML, CSS and HTTP.

Frameworks provide a higher level of abstraction and a more effective development workflow compared to using plain Javascript, but their pervasive adoption has, in my opinion, changed the web for the worse as more and more people started neglecting accessibility, performance and the simplicity of HTML and CSS in favor of script-heavy, Javascript-first websites.

When I was interviewing candidates for web development positions, I used to ask this question:

Can you send and receive data from a server without using JavaScript?

You would be surprised how many people struggled with this question and it speaks volumes about the current state of the industry. The question is open-ended and I used to ask it to get a better understanding of the critical thinking skills of the candidate and their knowledge of the web.

The answer to the question is of course yes, you can send and receive data without writing a single line of Javascript, this is the way the so called web 2.0 worked when languages like PHP, Perl and JSP were all the rage, the time before the concept of AJAX (Asynchronous Javascript And XML) was introduced.

The World Wide Web is still fundamentally based on HTML and HTTP, whenever you click on a link (the <a> tag), you are implicitly sending an HTTP GET request to a server, developers can set additional parameters in the URL by using the query string (e.g. /posts?page=3&size=10), you could then process the request using a server side language and generate a response dynamically.

You can also send data to a server without Javascript by leveraging the HTML <form> element, you can add input elements inside of it, the user can then fill the form and submit it via the <button>, here is an example:

<form action=”/create-account” method=”POST”>
  <input type=”text” name=”fullname”>
  <input type=”email” name=”email”>
  <input type=”date” name=”date_of_birth”>
  <button type=”submit”>Send</button>
</form>

When the user submits the form, the browser collects all the data from its input elements, it encodes the data using the mime type application/x-www-form-urlencoded and it sends them using an HTTP POST request to the URL specified in the form action.

People struggling with this question highlights a crucial disconnect: A lot of developers have completely lost sight of how the web actually works as they became overly reliant on frameworks and scripting even to achieve the most basic tasks such as sending data to a server, something that has always been part of HTML itself.

Another question I often ask is:

How would you create a button that navigates to a given page and scrolls to a specific section when the page loads?

Many people would do this using Javascript and other mechanisms from their framework of choice. The solution is actually quite simple and can be done using only HTML and CSS.

You can create a link with the <a> tag, style it as a button, set its href attribute to the path of the page you want to navigate to and specify in the URL fragment (the part after the # sign) the id of the HTML element you want to scroll to, here is an example:

<a class=”button” href=”/path/to/page#my-form”>
  Go to Contact Form
</a>

<!-- on the other page -->
<form id=”my-form”>...</form>

To enable a smooth scrolling animation you can do so with a single line of CSS:

html { scroll-behavior: smooth; }

This solution is simple, fast, effective, it uses zero Javascript and it works in all web browsers!

An over-reliance on frameworks and the lack of understanding of the fundamentals are some of the causes that made the modern web such a bloated mess. Navigating the internet today requires high-speed connections and devices with multi-core CPUs and it has become normal and accepted that a single browser tab consumes hundreds of megabytes of RAM, just to display some static text and some images.

HTML: The Foundational Building Block

Even today, HTML remains the foundational building block of all web sites regardless if you are building one using React, Vue, Svelte or even the good old jQuery. Quite often I hear developers making fun of HTML and underestimating it, these are also the same people putting it on their resumes, saying they are experts in it but then proceed in making everything as a <div> or creating a button like this:

const Button = (props) => {
  const handleClick = (event) => {
    if (!props.disabled) {
      props.handleClick()
    }
  }
  // additional code is omitted for brevity...
  return (
    <div className=”my-button”
        role=”button”
        tabindex=”0”
        ariaDisabled={props.disabled}
        onClick={handleClick}
    >Click me</div>
  )
}

I have seen this monster way too many times during my career, code like this is forcing a <div> to look and behave like a button, this is like trying to fit a square peg in a round hole and it doesn’t provide the same level of functionalities of its native counterpart.

The native <button> element provides a lot of built-in accessibility features such as keyboard navigability (tabbing to and activating with Enter/Space), correct semantic meaning for screen readers, and focus state management. You can also leverage the disabled attribute to actually disable the button without having to add custom code to handle this behavior. You get all this stuff for free and the only thing you need to do is use the proper HTML tag:

const Button = (props) => {
  // handlers ...
  return (
    <button className=”my-button” type=”button” disabled={props.disabled}>
      I am a real button!
    </button>
  )
}

A wrong usage of HTML leads to poor Accessibility and SEO scores, aspects that are too often being ignored in modern frontend development and that will soon start to have legal consequences for many public website owners.

Many websites serving EU citizens operating in e-commerce, finance, government and transports are now required to comply with the European Accessibility Act, a law approved in 2019 and already in effect since June 28th of 2025, which demands that public websites and mobile applications become accessible to people with disabilities, non-compliance can lead to fines up to one million euros!.

The introduction of this new legal framework requires a drastic shift in how websites are built as they must conform to the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA, an international standard maintained by the World Wide Web Consortium (W3C).

Following is just a small sample of things listed in the WCAG 2.1 document that frontend developers must take into account while building a website:

  • pages must correctly use HTML semantic tags and ARIA attributes to facilitate navigation via screen readers
  • websites must be usable entirely with keyboard controls
  • colors must have high-enough contrast for users with vision deficit
  • colors and content must be designed so that websites are usable by people with color vision deficiencies (deuteranopia, protanopia, achromatopsia)
  • animations must be designed/disabled for people with motion sensitivity

Semantic HTML will help making your website more accessible while CSS media queries can be leveraged to dynamically adapt the content of your website to people with different preferences (using light or dark color scheme, reduced motions, higher contrast).

Even in this day and age, websites still remain a collection of HTML pages connected via hyperlinks, we should strive to keep their nature as close as possible to how the web was originally designed and we should use scripts to enhance the user experience.

Companies must rethink the way they build websites and strive to conform to the WCAG standards, failing to do so properly can now cost them serious legal and financial consequences.

Did you know about the European Accessibility Act and the stricter requirements it demands for building websites? Does your website conform to the WCAG standards? If you would like to know more about this topic, feel free to contact me.

Contact Me!