Those who know me understand that I engage in an ongoing battle to make websites more accessible, driven by persuasion and my selfishness as a blind person. Through teaching, humour, and a hint of healthy irony, I strive to help people recognize the importance of creating inclusive products for everyone rather than solely focusing on disability.
On bad days (I have had a few lately; it might be due to age), my pessimistic alter ego takes over, and I think that, on the current path that websites are following, accessibility is frequently derailed, costing a great deal (even through legislation) to get it back on track. These are the days when you feel like shouting: fire, destruction! Every image lacking alternative text and every label without proper semantics, adorned with JavaScript, only reinforces that pessimistic mood.
But is this true, or when viewed from a different angle, is accessibility in better health than it was a few years ago? Let us provide a bit of context.
The evolution of the web
In many respects, 2014 was a year of transition. We were moving away from websites where it was customary to push a button or link that caused the page to reload entirely, which though slow, enabled screen readers to detect changes without difficulty. Although these were no longer “1990s websites,” native controls were still predominantly in use, making things easier for assistive technologies (despite jQuery and other JS frameworks, which had been around for several years, complicating matters with animations and dynamic changes). However, the shift towards a web that mimicked desktop looks and functionality and the need to adapt it for mobile devices accelerated many changes that would dramatically alter accessibility, particularly for screen readers.
Things were changing rapidly. Frameworks like AngularJS were increasingly becoming prominent, facilitating the emergence of SPA portals everywhere. Suddenly, we realized that when we clicked a link on a website, our screen reader remained unchanged, as if that link were broken, because screen readers, without some help, do not know how to interpret partial changes. Alongside SPAs, numerous non-native controls (those that cannot be directly expressed as an HTML tag) emerged, further adding to the chaos: accordions, drop-down menus, modal dialogues, and popovers, to name just a few examples. This made matters slightly more complex (and still does today), not due to a lack of technical solutions (available almost from the outset) but rather because of web developers’ insufficient knowledge and implementation.
Fortunately, as I mentioned, the technical solutions were available. In 2014, the W3C published the first version of a set of specifications known as ARIA (Accessible Rich Internet Applications) as a recommendation, which enabled the enhancement of web applications by providing essential information for assistive technologies to thoroughly understand the functionality of each element and respond appropriately to changes in their status. In fact, over the past ten years, ARIA has also evolved alongside technology, with version 1.2 being the latest recommendation published by the W3C in 2023 and version 1.3 presented as draft work in 2024.
Over the years, the HTML standard has also evolved, providing developers with the fundamental bricks to create more accessible and semantic websites. Labels to define a web structure (making it easy for technical aids to perceive) have been added, and new labels have been introduced to render controls that so far could only exist by making an almost obscene use of JavaScript (and therefore ARIA, to be accessible). For example, the <dialog> label is one of them, allowing us to create modals in a straightforward way rather than using JS libraries to simulate them from scratch.
Frameworks such as React, Vue, Angular 2 and Svelte have established themselves as leaders in web application development, chiefly due to their capacity to create highly interactive interfaces and enable partial updates almost instantly. However, accessibility has suffered greatly, as effectively conveying all of this to screen readers necessitates additional effort from developers who must comprehend and implement ARIA correctly. I should also mention that deploying ARIA correctly in increasingly interactive and complex web applications presents its own challenges.
The critical role of component libraries
All modern JS frameworks share one common feature: the use of components. Components are fragments of an application that can be reused and customized in various situations. For instance, we could create a component that renders an accordion with our desired options, another that displays an edit box with a tooltip, or another that presents a horizontal menu that, on a mobile phone, seamlessly transforms into a drop-down menu to occupy less space. As nearly all applications utilize common components, component libraries have emerged. These libraries consist of a collection of packaged, highly customizable, ready-to-use components that are remarkably easy to use.
As you can imagine, this makes it much easier to build an application, as a developer does not have to write its components from scratch but only has to use the components that already exist in their libraries. So, if many developers widely use a library which implements good accessibility by default, the applications that use it will be much more accessible without too much extra. Shazam! However, the opposite can also occur: a widely used library may not implement accessibility by default, making it very difficult for applications using it to be accessible.
Fortunately, many of the most commonly used component libraries implement accessibility features to a greater or lesser extent (sometimes messily, it must be said). In recent years, we have seen how many applications have improved their accessibility, in many cases without the developers’ intervention. That is great about reuse 😉.
The good news is that many libraries are open source, so we can always make a pull request to improve thousands of portals with a single action. Reuse again!
So, which is it? Are we more accessible than we were ten years ago?
Despite those bad days I mentioned at the beginning of this article, the answer is a resounding yes. We have improved greatly on some issues, though there is still a long way to go.
A growing awareness
I think that ten years ago, web accessibility was a concern only for a small group of developers who were intimately aware of the barriers that an inaccessible web could create, and that made us much more committed to its implementation. Today, society is changing, at least in much of the world, and I believe it is increasingly committed to the values of diversity, equity, and inclusion. This is gradually being reflected in the development world, where more and more people are seeking resources to train in accessibility and are dedicated to incorporating accessibility into their projects.
Laws and fines also help
Since 2007, Spain has had a fairly clear law regarding web accessibility, both from the public sector and from significant private companies. While its implementation so far has been relatively limited (not to mention painful), countries like the U.S. have enforced their laws more strictly. Due to globalization in the digital realm, this has had a noticeable impact on the rest of the world, especially among large multinationals.
But even though so far, the U.S. has been at the forefront of positive changes in accessibility due to their legislation, starting next year, in Europe, we will also experience a turning point towards more accessible portals, with the European Accessibility Act coming into force. This law will apply in all member countries, and it will demand, starting in 2025, that any new content of great significance, both from the public and private sectors, comply with UNE-EN 301 549, which, in addition to some additional points, means to comply with WCAG 2.1 at its AA level. Now you can imagine me jumping out of joy and saying: it was time, dammit, it was time!
Just as the law has not been applied in Spain, I hope that, as this is a European law, Spain cannot ignore it and let the complaints pass through as it has been doing so far. I hope time will give me the reason.
The commitment of large companies
In recent years, companies such as Microsoft, Google, and Apple – organizations that market numerous digital products widely used around the globe – have made a genuine commitment to accessibility in their developments. They have implemented protocols that ensure these products consistently maintain a high accessibility standard over time.
Beyond the positive impact on their products’ accessibility, Google and Microsoft have also positively influenced the accessibility of third-party products. For example, by including accessibility testing tools in Chrome and Edge, Google and Microsoft have delivered a clear message about the importance of accessibility, which has made other developers consider applying it to their own projects.
Today’s accessible development
Technology has evolved significantly over the past decade, as have the capabilities to ensure accessibility. Today, the available tools, standards, and frameworks enable applications to be fully accessible. The use of ARIA, accessible component libraries, and, above all, a proper application of the HTML standard allows current applications, despite their complexity, to be entirely accessible.
However, this is only possible if developers possess the requisite knowledge and consciously apply best practices to their projects. Accessibility remains a challenge of training and commitment, instead of being a technical barrier.
Accessibility and fragmentation
Although initiatives such as ARIA have evolved and theoretically address most of the needs of today’s web applications, it is true that, in practice, numerous problems persist with the heterogeneity of their implementation. Consequently, some browsers interpret ARIA specifications subtly differently or provide varying levels of support for certain attributes, as well as for the accessibility features of native HTML controls. Moreover, screen readers do not uniformly support the entire ARIA specification, and there may be discrepancies based on the operating system they are operating on. Thus, the same web application may offer varying degrees of accessibility depending on the combination of browser, screen reader, and operating system, which regrettably reminds us of when we had to implement patches on websites to ensure functionality across as many browsers as possible.
Fortunately, this is changing gradually, and ARIA implementations are consolidating to align with specifications (improved documentation of new ARIA versions is also helping). Likewise, the implementation of the latest HTML controls is being matched across browsers, and the accessibility experience has fewer and fewer differences. However, we still need all involved players to continue working together to completely eliminate that heterogeneity and make an app accessible on equal terms regardless of the screen reader, operating system or browser it runs on.
Training, the root of accessibility issues
I personally believe that the lack of training for developers is the fundamental issue concerning accessibility. Based on my experience as an accessibility consultant, I have arrived at a regrettable yet undeniable conclusion: most web developers have a limited understanding of HTML. It’s akin to a mason being unaware of the significance of a solid foundation when constructing a house. One can arrange bricks in any configuration, filling gaps with whatever materials are available. Still, although the end result might appear sturdy to the untrained eye, those structural deficiencies inevitably lead to complications over time. In much the same way, poorly structured HTML develops barriers that, while not immediately obvious, directly affect those who rely on accessibility to navigate or interact with the web.
Similarly, there is currently almost no training in accessibility included in the training programmes of bootcamps or universities, and this constitutes the second part of the problem. It is essential that accessibility is studied not as an extra subject or a solution to be applied when necessary, but as an integral component of web development, just as we do with good coding practices, design patterns, or unit testing. Until this changes, accessibility will continue to be viewed as an addition rather than a fundamental aspect of proper development.
What will accessibility bring us in the coming years?
Technology will continue to evolve, and accessibility capabilities will have to be on par to avoid being left behind. With the current legislative framework, I believe accessibility will continue to improve exponentially, not only because much more will be considered but also because of the intervention of artificial intelligence.
Yes, I know. Now, it seems that everything must utilize artificial intelligence and if not, it no longer matters; however, I am convinced that it will play a vital role in accessibility.
In fact, in the past year, screen readers have begun to incorporate interface descriptions using GPT Chat. For instance, if I encounter an unlabeled button on a website, I can request my screen reader to send the graphic representation of that button to GPT, which will return a text explaining not only what is visually displayed but also its meaning in the context of the screen where it appears. Now, imagine integrating this into a browser plugin that utilizes AI to tag all unlabeled elements of an interface on the go, and that, based on the visual structure of the page, can add all those HTML sections that humans have omitted in real time. The same could apply to form field labels and the inclusion of attributes to indicate the obligatory nature of those fields based on colour, etc.
I believe that all of this will arrive soon and will greatly enhance our experience with products that have not been designed with accessibility in mind. Naturally, using AI to correct our mistakes should not be the standard practice, but rather a last resort, ensuring that products remain inclusive, even if they are not functioning properly well.
We may also apply all this to accessibility testing tools, which currently rely solely on HTML and the CSS generated to assess whether a website is accessible. Such tools can detect at most 40% of errors, but with the assistance of AI, this percentage is set to increase significantly.
Conclusion
Web accessibility has improved over the past decade, yet we still have a long way to go. Despite technical, legal, and training challenges, we have witnessed significant progress in both awareness and available tools. Accessibility is no longer a concern for just a few; instead, it is a way of thinking and empathising that is beginning to ripple into the development culture and DNA of many companies.
Despite progress, fragmentation in standards implementation, lack of training and lack of knowledge remain important barriers. We must continue to work to make accessibility a fundamental pillar of web development, not a patch that we apply a posteriori when there is no further remedy.
Are we truly on track? Without a doubt. There will be bumps and setbacks, but also shortcuts, and in the end, we will prevail. Despite a few “bad days,” I am convinced of it.
Recommended citation: MONTIEL, Juanjo. The evolution of web accessibility over the past decade. Mosaic [online], january 2025, no. 202. ISSN: 1696-3296. DOI: https://doi.org/10.7238/m.n202.2412
Deja un comentario