When I joined Wordbee last April, I remember talking about accessibility during my first work interview. Until then, the topic had not really been discussed at Wordbee. I remember explaining how I used a computer and demoing some of the applications I used on a daily basis. For those who didn’t read my previous post, I am blind since birth and I am professional translator and interpreter. You get the idea: I can use CAT software and web applications only if they are built with visually or otherwise impaired people in mind. Most web applications are useable for me, more or less, but often in an inefficient manner.

I already discussed the basic principles of accessibility in another post back in July, so if you aren’t very familiar with what I am discussing here, feel free to give it a read!

Anyway, hearing the positive feedback which came out was amazing: I started thinking, indeed hoping, that thanks to my contribution, little or big as it might turn out to be, I would have the chance of changing the rules of a game which saw disabled translators at a bad disadvantage, not because of lack of skill, but because of software inaccessibility.

Let’s put things straight right away: A lot of Wordbee Translator is indeed accessible as are most web applications thanks to the magic of HTML. But accessible and truly accessible is not the same thing. Do you prefer a phone from 15 years ago or an iPhone or Android phone? I think you get the idea.

When I arrived, I started with creating a “task force” to make all the company aware of the issue and the steps we need to take. I introduced accessibility to the developers, things like “aria” attributes, screen reader notifications and other tech topics. Given the team’s incredibly busy schedule scratching out time for this “elite” topic was not always an easy task.

Explaining what accessibility was all about, conveying how blind people “see” what is on screen was one of the hardest challenges I had faced in the last three years at least. Even though I consider myself a pretty advanced computer user, I am no developer although I do know HTML and I do grasp general programming concepts (I am able to program in good old C). What I had to do was researching and reading technical documentation on the subject, something which I had not really considered before.

The first meeting finally took place on a sunny Wednesday afternoon, and the response I got was mind blowing, even though talking about technical stuff to people who were far more technically minded than me made me feel a little awkward, I’ll admit.

I remember showing the guys my screen readers for both Windows and Mac, how a braille display works, as well as the behaviour of a screen reader when both semantically correct and incorrect HTML are used.

But there was more: even though I did know HTML, I did not yet know ARIA in-depth, the specification used to augment web widgets in order to make them understandable by screen readers and other assistive technologies.

So not only did the devs learn accessibility, something many of them had not considered, but I learned too. I had to grasp technical concepts which were not really my field, and this certainly took effort but I was more than willing to do it.

I got a lot of interesting questions, and we engaged into discussion afterwards about what could be done and how to implement screen reader support correctly. They were to think about the technical part, whereas I would take care of how the accessibility user interaction should be performed.

But it was not until late July that we started serious work on the matter. We agreed to have two meetings per week in which I and Florent, a front-end dev, would work together: he would code, and I would test and offer suggestions for what my competences allowed me.

And that’s also exactly when we started to realise how difficult this journey would be. Indeed, accessibility is easier to implement when you consider it from the start, but when awareness comes later, there’s a lot of code you need to change completely in order to make some particularly nasty widgets workable through a keyboard and a screen reader; this happens especially when they are not made through native HTML elements but rather through generic tags, which are then augmented by means of Javascript, CSS and other technologies.

Add to the problem the fact that many widget design tools automatically (mis)place aria roles for accessibility out of the box. Problem is, they often don’t do what you intend, so every time you have to undo their attempts at accessibility and redo everything from scratch.

Are we getting there though?

We definitely are. Some things already work, some do not yet, but it’s starting to be so much less painful than it was at the beginning. The extremely positive factor is that, here at Wordbee, we are a really united team. When we perceive a goal, everyone puts their maximum effort into the task at hand. This is why Florent wrote an extensive document for all the developers, who are stepping up to the task of contributing to accessibility as a real task force, everyone with their own code and their own ideas.

I should devote another article to discussing what works and what doesn’t in more detail, so stay tuned for future updates! For those who want to see the results today, you will need some more patience. Our work actually is for the brand new translation editor Wordbee is currently building (a truly amazing piece of work let me tell you)!