🥉Three winning principles for accessible public services

Simon Mulquin
3 min readJun 18, 2022

This blog post is a part of my notion page on web accessibility where I share my learning as a developer of public interest services.

Find the updated knowledge here and feel free to improve/share 🙂

Now here is the current version of what I think are the three winning principles for accessible public services today, enjoy 🎁

🤕 Do not harm

It seems obvious but most of the applications we use still harm a lot of people.

Public services, for exemple, are often designed in a concrete unaccessible way considering people’s needs and obligations to use these services are a good reason for them to adapt.

On the other hand, they are still services and should aim to take care of their beneficiaries, no matter their age, health condition, culture, location, language and more.

This guide will help you emphasize with these people and help you make your services more accessible step by step.

🧑🏽‍🔧 Build transversal

When you create products or build a place, you will work closely with technical teams not only to achieve a plan but also to define the plan.

As a person, you will not be able to understand the complexity of the whole system you are building and these people will give you technical insights while you will expose different problems.

Technical workers are not only doers but also efficient ****problem solvers and should be included in design phase or loop.

Would you plan a trip on moon without astronauts ? No. It’s the same complexity for any field or expertise, no matter what your ego says 🙂

Now if I ask… Should astronauts plan to send random people on moon, would they do that without doing a medical checkup first ? No. And so you wont build your rocket project without user research.

You don’t have enough resources for user research ? Then you are probably building for everyone and it’s great, but you will have to include every possible users to make you design really accessible.

It could be really hard, if all these tech teams works in separate environments, to connect them with every users need. Actually, you won’t have enough of a life time to make it.

But what if all these people are able to collaborate not blindly following a Y axis communication but operating around an artefact designed to give them the more informations they need, from the user and every stakeholders ? This is when you will consider your service fully transversal.

🧘🏽 Build less, learn more

Finally, you will probably want to save time and money on your projects, it’s good, we don’t want you to splurge public money on meaningless projects 🙂

When you may feel like there is a lot to build while reading about accessibility, you will also acknowledge you can’t anticipate everything and should’t. Designers and developers can easily sense when they are about to lose time on something or, on the contrary, when there is much thing to do.

They will give you precious insights than you should listen to and your beneficiaries will do just the same. Your main goal is to learn from both and assume when you don’t know.

As an exemple, there is no need to create a localization process or engine for you to give internationalized content if you have no idea how to make it, you should then not do it, document the unknown and observe it. The challenge is not to be blind, wich you will be if your process is so unaccessible that the people with issues will not feel like you actually want or are able to hear from them.

Try to build your services in an iterative and organic way, step by step, alongside with the beneficiaries and the people you work with.

Do you want to learn more about my missions ?

Follow this link, you’ll be redirected to my public notion page.

Thanks for reading !

--

--

Simon Mulquin

Fulltime curious guy; freelance in public interest IT; passionated by human sciences, territory development and privacy; I write in french or english 🙂