The magical construction office

Imagine you are planning to build a house. You managed to secure a property (and people tell you that it's relatively easy, compared with years ago), but you are aware that this is only the first step towards the dream of owning a house. But then somebody approaches you and tells you of a central office, where you can get building plans and even building materials for free. Sure, they say, you can always hire an architect, but the office is so well-assorted that you will find plans and materials for the vast majority of things related to a house. You could even find building plans from all over the world there! And while there aren't construction plans available for every imaginable type of house, room, gable, or balcony – the office still has construction plans and materials for the most common things you can build in the context of a house.

The creators of the plans you can find in this magical office even did take care of accessibility. Everyone can enter the buildings you construct with their blueprints, because the creators do conduct frequent tests with a diverse group of people, aiming to ensure that everyone can enter, navigate and leave their buildings. And if you are a fan of timber construction or red brick houses, you find most likely a special plan just for that lying around.

In order not to overstretch the metaphor even further: You likely noticed after just a few words that this "magical office" is the web, and both construction plans and material are open-sourced code. But the comparison deliberately does not end here. It is not only some code useful for building websites. The magical office has actual well-vetted design systems, component libraries and page compositions, coming from creators that have to make sure their code works for a maximum number of people – governments and players of a country's public sector. And because these self-committed to standards of web accessibility (rightly so!), the open-sourced code has to be accessible by definition.

As a consequence, we as builders can benefit from the research and development work that has taken place and are actually in a situation of visiting a site where you just have to pick and choose and don't have to reinvent the wheel (or pay other people for reinventing it). Consider the luxurious situation we builders are in, and how unreal it would sound if this "magical office" principle would apply to other industries.

But I think the comparison to actual buildings is actually apt because websites are becoming more and more part of the every-day infrastructure – and this even before the time of a global pandemic, where all humans have to physically distance. For some people, even pre-COVID, the Internet was the only way to do business, shop, buy things, get information or participate in social life. It is the great tragedy of web development that this group is forgotten again and again. In large parts of the education of the industry, in tutorials and often in agency or freelancer practice. Sadly, the "stick" part of the "carrot vs stick" spectrum had to be used - but to welcome that the people behind the "magical construction office" also tighten the thumbscrews at the same time. Web accessibility laws are not only strengthened and unified for the government websites themselves; there is even a silver lining in the form of the European Accessibility Act to move the needle in banking, transportation and e-commerce.

You might wonder why I limit this comparison to public sector design systems and component libraries. It's that most governments have given themselves accessibility laws for their own government websites and apps. The chance that their code adheres to standards like WCAG 2.X in one way or the other is greater than with published systems and libraries from the private sector. Given there are some open and accessible codebases that adhere to accessibility standards as well, the probability of having a solid, tested and inclusive library is simply a little bit higher with governments' code.

That, of course, doesn't mean that every open-sourced web interface code is automatically perfect. It is still useful to do at least the following checks:

  • Is the library specifically referring to an accessibility standard like WCAG 2.0 or WCAG 2.1?
  • Alternatively: is it public knowledge whether there are specific web accessibility laws already in place or just around the corner? It's only logical that the released code adheres to the standards as well
  • Is the code merely on GitHub (or somewhere else public), or does a blog or some other communication channel exist where the team speaks of their testing process, overall aim and updates?

To get to the meat of the article (and to reveal that it was a mere listicle article all along), I'm aware of the following resources of great and well-tested libraries:

Please do contact me via webmention, Twitter or e-mail if you know of more good ones!