Angela P Ricci

The training was completely designed by me, based not only on how I believe is the best way for people to learn web accessibility, but also as a way to show developers how important and interesting their work could be if they think about accessibility while coding.

During the two days of training, I don't talk about the WAI/CAG criteria at all. Instead, my goal was to “instil an accessibility mind-frame”, to make people learn to “ask the good questions while coding”, and to know where to search for good solutions during their work. The use of screen readers played a big role on this training, so developers could “listen” to what they were coding.

I believe that reviewing every WAI/CAG criterion can be very tiresome and people may loose interest after half a day of it. Therefore, I designed the course based mostly on HTML — something that any of the “full-stack” developers that I've trained really knew — and the importance of semantics: choosing the right HTML element for the right content.

In front development, if you rely on semantic HTML, you're already doing most of the accessibility work.

One of the examples I used in order to show how important it is to choose the right HTML element, was the most iconic one: buttons versus divs. I explain what we have to do in order to “transform” a DIV element into an accessible button:

<div class="button" onClick="open()" role="button" tabindex="0">Click me</div>

Unfortunately, we still see lots of examples like this. Developers love to make buttons from divs, and instead of “wasting time” looking for the proper HTML element for the job, they prefer to waste their time by making a div clickable, focusable and able to present different states — not to mention the wasted work on styles.

I think — I still think that, in spite of all the frustration — this example is a very powerful one to make developers understand the importance and simplicity of semantic HTML: just use the button element!

As Bruce Lawson once put it — I couldn't find the source again —, using the right element for the right content gives you “accessibility for free”. We don't need any extra effort or to add any extra attribute or role, and if we want, we don't even need to add style: our button already looks like a button, even without CSS.

In the first day of training, I go back to this example several times.

The second day of training I approach form accessibility and give an introduction to ARIA, as well as some exercices so the developers could get a grip of how ARIA can improve — and also jeopardise! — web accessibility. One of the exercices was to code a simple dropdown: a button that would toggle the display of a list of actions.

I cannot explain my feeling of frustration when one of the developers showed me an example of what he had done for the toggle button:

<div tabindex="0" (click)="open()" (keydown)="open()">Open</div>

Hu...really?

The worst part was that he didn't even understand why I was so surprised! I was angry also, but I hardly managed to hide it.

I know I'm not a natural teacher and that I surely should question the way I explain things, but oh boy! That code was simply telling me “all you said yesterday was useless”.

Another point of frustration comes with the full-stack developpers who I've teached. Not one of them had basic understanding of HTML or CSS. For most developpers, even Javascript won't come easy. They're full-stack because they have to work also with the front, but they touch it as little as possible, and I'm sure that the little they learned during my training, they surely forget with time.

Those are just some examples among many, many others. All this time I've been teaching accessibility I've accumulated so many disappointments and frustrations that I can no longer see myself teaching.

I assume all the blame, though; and the frustration is big exactly because I have to admit that I'm not able to express my passion and inspire others with my experience as others inspire me with theirs.