My goals for accessible web technology

As one of the savy tech guys of the team I have set myself technical goals I would like to reach for all our clients and our own work. And since these goals are important to me, I might as well share them with you all.

The main goal

My main goal is best described by the words of Marijn the Vries, an UWV employee. As someone who uses a wheelchair he stated "There are more and more places that allow me inside, but there is a difference between places that allow me to enter and those that welcome me."

And that is the pinnacle I want to reach on the web, I want all my website users to not only be able to use what I make, I want them to feel that I made it with them in mind, that I strived to make them access with what I build.

I do no longer want to develop software to be a wonderful shoot for the moon experience for all the abled-bodied people and then make it a "compliant" website, for all those people who experience limitations. I want to develop a UX thrill for all the senses and for the range of our mental capacities, rather than only for the majority.

The intermediate goals

So, how to reach this goal, I broke down my goal in the following intermediate goals.

Technical depth and adaptability

Accessibility is a part of the technical quality of your website. You can relate the topic to the topics of security, performance, stability and privacy. These are all topics that are not part of the functionality of features that we deliver to users. Instead, they are things we should think about with every feature we develop but the do also cost us time if we want to implement them well in every feature we develop.

This is a balance we always need to keep while developing, we want to get as features out to clients as quick as possible and we will avoid overengineering these features, while also wanting to avoid such a drop in quality that users become disappointed when using what we made.

And it is very hard to figure out what the right balance is while developing. You can spend time trying all kinds of SQL injections on your forms only to find that nobody even wants to log in to your application or you may run rush an accessibility event post and find out your form is not accessible afterward.

The best strategy to deal with this is just to know exactly how much time you should spend on everything and never be wrong.

If that is not an option for you, like it is not for me, you should focus on being able to quickly and safely making changes to fix your shortcoming. So for strong basis I will be focusing on the topics of refactoring, lowering technical depth and adaptability of what we build.

Compliance

Once our codebases are in a place where we can easily a safely change what we made we can focus on reaching compliance with the WCAG. As said, the only delivers the virtue of allowing those with disabilities into our application, we are not welcoming them yet, but we are not denying them entrance either.

To get to compliance I will be focusing on the different testing methods: manually, assisted, automated and getting audits in.

Know your accessible tech

Just like all other tech, the better you know all the CSS, HTML and JS features you can use to build and accessible experience the more likely you are to deliver a wonderful experience.

Of course it does not end there, you also need to be aware of what features your designated frameworks and tools can leverage in accessibility and what shortcomings they have so that you can advocate to get them fixed.

Know their assistive technology

Next to knowing your own tech stack well you should know the technical functioning of assistive technology, how to use the technologies and you have to be advanced enough with them so that you can test drive the experience what you are developing with those tools.

Know your users

And as the last, and most important closing step in developing for a wonderful experience you should know your users with disabilities, and welcome them to use what you are making. Not only does this involve user testing and getting regular feedback from your users, what your aiming for here is getting compliments and mentions about the unique auditive or keyboard design experience you developed.

And talking about compliments, I need to thank Marjon Bakker she made the case for thinking about designing experiences rather then thinking about compliance.

Critic: You can not design for everybody

A common response to wanting to design for everybody is: you cant keep everybody in mind when you design. And yes, this is true.

You can not imagine both all the different disabilities that affect using the web or its content and you can not fathom the wide diversity in lived experiences of those with the same disability. For instance, all you know about all the people in a wheelchair is that they are in a wheelchair. You do not even know what limitations the disability offers let alone who completely different the individual is. I mean, do you truely want to attempt to compare the lives and mental worlds of Wolfgang Schäuble with that of Stephen Hawking? Even within their disabilities, they do not share the same cause or the same type of wheelchair.

But, lets talk about the big hairy but here we are unwilling to face. Because underneath this argument is a ableism. It suggests that we are incapable of fully understanding and perfectly developing for the wide and diverse groups of those with disabilities, and worse, that we should not even bother to try, but that we would be capable of the feat of fully understanding and perfectly developing for all those without. And we are not, we will never make a perfect design that is considered "the best thing ever"by all those who are without a disability. So why draw an arbitrary line between fall short of your goals between those with and those without disabilities?

I am not saying, stop shooting for the moon, I am saying, there are a bucket-load of neat planets out there, shoot for them all. And if that is not enough, may the words of Samuel Beckett become your mantra:

"Ever tried. Ever failed. No Matter. Try again. Fail again. Fail better."