Considerations about accessibility

One of the most important and interesting lesson of the course I teach at Fictizia is about web accessibility. I always try to transmit the idea that it is something wider than “We should make our site accessible for blinding people” (which should be the most spread conception) so we should think globally.

From my point of view, we have the responsability to build universal and accessible digital products (products that an user could access) that could be used and be useful for the people, trying to avoid making them not useful due to its design or functionalitites.

NOTE: If the idea of making the right thing is not enough for you to adopt this apporach, remember that a product that is useless will probably not report value since it could not be used.

Expanding our mind

First of all, we need to understand that there are a lot of issues that affect people and these becomes limits that make our products or services useless. These issues could be temporary or permanent. And they could be visual, auditive, motor, cognitive or technologic (because a site that does not care about its perfomance could result not accessible for devices with lower skills or with a basic connection network). In the worst of the cases it could be at least two of them together. Since there are a lot of combinations, it is always a good idea to check out the Funkify project and its extension for Chrome because it helps to make those profiles more visible and expand our mind.

Another considerations

The issues related to accessibility should appear while our interface grows and becomes more and more complex. So, web technologies are accessible by default but we (designers and developers) twist them untill we make it not accessible. Sometimes it is the result of a wrong decsision taken when building the site but in other cases we have the need to build something that has not an equivalence with a native element, so since we need to create them from scracth we also have to give to it some capabilities and oftenly we do not do it; because of lack of time, definition, because is out of the scope of the project or maybe the client do not want it since the most of the times it implies an extra developong time.

Tipically, the accessibility wrapper is built at the end of the project, and should be added as a corrective factor, which means that we have the need to modify our code to make our interfaces interpretable for assistive technologies.

But it will not always means an extra effort, because once we have integrated some good practices in our working day, taking care of accessibility at our interfaces will not suppose an extra effort.

How to get started

After taking consciousness and assuming our responsability, we discover that there are a lot of accronyms, rules and new concepts to learn and tons of documentation, which make it more difficult to getting start from the beginning.

From my side, I always recommend the same, keep calm. There are a lot of information out there and the effort to integrate it in a single shot is huge, so the best way to proceed is step by step. For example, we could focus on the basis and after understanding and using it so feeling conformtable we could add more and more complexity. Then after some time with this approach, we will look back and confirm a real an progressive advance, we will feel it natural and more satisfied.

Starting from the beginning, the best idea is to check out the official WAI, WCAG and WAI-ARIA documentations. But since it is not the easiest information to extract and digest, we are going to highlight the most interesting parts from these specs from here to you.