Accessibility in everyday applications

Taking care of its individuals (all of them) has long been a sign of evolution in a species. Cavemen took care of each other, as they saw the benefit of having people of different profiles who can see things from different perspectives performing complementary activities. 

Human evolution must reach the software development community. Accessibility must become a quality everyone takes for granted. All software must be inherently accessible. People with disabilities (PWD) must not get stressed whenever they are required to use a particular software application for the first time. “Will I be able to perform that required task using the recommended software?”  

Unfortunately, in most circumstances, the answer is No. There are tons of different approaches to bringing accessibility to applications. Operational systems provide accessibility and accessibility services. There are free and independent accessibility checkers readily available. Governments support accessibility in software providing free sign language animated avatars. Still, private companies provide accessibility as a service, which can be embedded into apps per call.

So why do most applications still lack accessibility? We, as HCI people, argue that it is due to learnability and effort. Devs and designers need to learn something new: how to configure some software and use a particular framework in their apps. And that’s one (or more) thing devs need to worry about. Needless to say that the stack of technologies devs need to master keeps growing. Add to that the feeling devs get of not being assured that using that technology configured the way they did will do the job. So software configuration and framework use suffice? Furthermore, what kind of disabilities are we covering? 

As for interaction designers, the set of challenges is different. How will we know that the user journey is attainable by a person with a particular disability? Will a person who is blind or visually impaired be able to schedule an appointment with a physician? Will a person with a hearing disability be able to interact with a chatbot? 

At FFIT, we have a different approach to these issues. We take the concept of the micro front end and extend it. First of all, we build them to be accessible and embeddable into both mobile and web applications. And we make them a bit larger than most MFEs. Being a bit larger make them closer to micro-user journeys, bridging the gap between designers and devs. Furthermore, our MFEs can also be seen as live components available at design time (through our own exclusive Figma plugin). Finally, our Figma plugin also generates accessible HTML code, which can be used in usability tests, as this code enables close to the final product experience. 

Want to take this conversation forward? Contact us 

FFIT, Humanity, Productivity.