Why every Developer should know how to make Websites accessible

Hand-coded websites are reminiscent of a somewhat glorified time. Somehow I always think of my grandmother sitting by the fireplace knitting jackets for her little grandchildren. Although I'm sure my grandmother never sat by a fireplace in tropical Goa.

Nowadays, however, you can hardly get around frameworks. Sure, you can maintain the website on your desktop and then upload it via FTP. Or use minimalist Content management systems. But for modern interfaces that should be chic but also functional, this is probably no longer the best way. Who still has the resources to programme an accordion, a flyout navigation or a slideshow and test it on all kinds of devices and browsers? Public IT certainly doesn't, and neither do their external service providers.

Now, the developers of these libraries and many Content management systems have hardly bothered about accessibility so far. It has been so exhausting for them, too. But the wind will change very soon.

Harder guidelines, more concerned

Every now and then it is important to remember that the german law BITV has not just been in place since EU Directive 2102. The first BITV is just turning 20 years old. Those who are only now taking care of it have so far criminally neglected their duties.

However, the development around 2102 has now caused a high degree of nervousness. Websites are being monitored more and more and accessibility bugs are being ironed out bit by bit. A reason to get rid of unsuitable frameworks and replace them with ones that support accessibility.

Now, public IT makes up a good part of the digital infrastructure. That alone would be a reason to pay more attention to accessibility in order not to lose this market. But a good part of the non-profit sector is also committed to accessibility. This should affect a good part of the internet.

A current example: the new BITV test requires the accessible transformation of content, i.e. if a PDF can be created from an HTML page via the website, the resulting PDF must adopt the accessibility information from the HTML. Hardly any of the currently offered libraries for PDF conversion can do this.

Of course, most of these frameworks come from the Anglo-American world. There is also strong pressure there, especially in the USA or Canada, through tougher laws and waves of lawsuits.

Of course, this is especially interesting for commercially distributed frameworks. But the free providers are certainly also interested in a wide distribution of their frameworks. What is the point of further developing a library that nobody uses?

It will get easier, but not simple

It is true, however, that the developers will have their work cut out for them. But they still have to deal with accessibility. After all, the libraries already partly offer the possibility to add ARIA or other relevant features, to change the contrast or to correct the focus.

Or to put it another way: you can produce crap with a good framework and achieve good results with a bad framework.

But the work is made much easier by good frameworks. Keyboard handling, focus management, minimum contrasts, ARIA states and so on are much easier to implement once they have been centrally integrated.

Perhaps in the future we should stop targeting individual organisations and instead target the developers of the frameworks. That should have a much greater impact.

A button is a button is a button

If something looks like a button and if it behaves like a button, then in HTML it should be a button.

As a quick explanation: You can design-wise create something that looks and works like a button, but the code is just JavaScript placed behind a graphic that looks like a button. Why do you do something like that? Because you're either lazy, stupid, or both. The effort to create a real button in HTML is exactly 0 percent higher than to underlay a graphic with JavaScript. Stupid because you obviously have no idea how to write proper code and you're probably using some application that clicks the elements together. As an absolute layman, I could create something like this in HTML. If you call yourself a web developer, you should be able to do it, that's the basics of web design.

Of course, the same applies to all other areas. Those who use HTML and CSS according to their purpose have already fulfilled a large part of the accessibility requirements. But that's really no feat. But anyone who still spoils their website with div id="navigation" today has no idea of their craft.

Now you can argue that nobody cares about the spaghetti code, after all it should look and work well. But no, it comes with massive disadvantages. A client convert the "Content" container to a reader-friendly variant. Google can cleanly distinguish the content from the navigation or the footer. So if you don't code properly, your position on Google will deteriorate, among other things, in addition to accessibility.

And of course the screen reader: It can recognize that something is a button and the blind person can jump to all the buttons on a website. "Clickable, clickable, clickable" on the other hand is not helpful for blind people. But if you're interested in usability for the blind, the main thing is that the box has rounded corners and a cool effect.

What's worse is that we still have to talk about such topics that we still come across unlabeled form elements and stuff like that.

Find accessible solutions

But what about complex dynamic applications such as calendar widgets or lightboxes.

In fact, for most complex use cases, there are freely available patterns or solutions that can be adopted or at least copied. So today it would no longer be a problem to foist accessible websites on customers, so to speak, whether they want them or not.

Researching and installing an accessible solution takes just as much time as installing a non-accessible solution.

Design criterion: Looks better

If there is one issue in accessibility that is not taken seriously, then it is the contrast. This applies in particular to text and ui elements. We've gotten so used to having to zoom things that we don't really notice that we are doing it.

The designers' argument: it looks better this way. If design is about making things look good, then the mission is accomplished.

But actually we thought we should use the website or application. Of course, sometimes you need a certain aesthetic appeal. But can it really be exhausting to be able to recognize, operate or read something? Is making beautiful the only professional goal of designers?

When surcharges are justified

Of course, there are other accessibility requirements that are quite complex. Adapting the patterns to your own requirements, for example, requires additional effort if the developer has to get used to it. However, patterns always have to be adjusted, for example for design reasons.

An exception also applies when external accessibility experts are involved. Of course, they want to be paid separately.

Another exception applies when specific tests are also carried out with disabled people. These tests are complex and expensive. A fee or an expense allowance may also be paid to the test subjects.

In addition, additional agreements with the client may be necessary in the context of accessibility. For example, a consensus must be reached on which standard must be met and what additional requirements there are.

I am not talking about special requirements such as plain language or sign language here. Here, of course, the costs are considerable. But that has nothing to do with the web agency.

But for everyday programming, high surcharges for accessibility are rarely justified. Many discussions and problems would be avoided if web developers simply wrote clean and intended code. The same applies to native apps. Simply read the guidelines of the OS providers and stick to them, that seems to be too much for some developers. It borders on refusal to work or inability.

In my opinion, several crucial aspects are missing:

The issue of accessibility is neglected in training.
There is a lack of sensitivity among those responsible, both developers, designers and clients.
Basic manual skills are lacking. I see this again and again in my work with developers. I actually had people in developer training courses who didn't know HTML. Your skills are limited to pushing boxes back and forth.

All the arguments such as time pressure are not convincing. Doing something twice, once wrong, once right, has taken more time and resources than doing it right once. And unfortunately, too many people get it wrong twice.