- PART 1 – UI versus UX – Differences and History
- PART 2 – UX/UI Design and Product Life Cycle
- PART 3 – Users, Usability and Common Design Pitfalls
- Part 4: Users, Accessibility, and Common Design Pitfalls
- Part 5 – UI/UX Design: The Color Theory and how it helps
- Part 6 – UX/UI Design: Prototyping Essentials
It has been noted, many companies focus first on usability, and then they shift towards accessibility. We believe that this is not the right approach. It is considered right when they are practiced together. In this part, we will cover some important aspects of accessibility, how UX approaches it, and what are the pitfalls when companies actually consider them.
Accessible User Experience
Which kind of design would you consider to be the most useful? I would say a design that is accessible to all users irrespective of their limitations. It means that a design that does not make any distinction between users. It is not dependent upon a user’s ability to make use of that application. This includes users with special needs.
And this is called designing for accessibility!
All kinds of disabilities except a few have some kind of relationship with your product or service. And in particular, some disabilities and conditions have a special kind of relationship with your product or service. So planning is important for all kinds of audiences within the quadrant of accessibility. You might need extra resources, but they are worth a lot in the long run.
Sounds difficult, doesn’t it?
As you move through the design process, you can work on the special kind of users and incorporate them in the product usability i.e. make your product accessible to them.
Our Responsibility to our Users
The users with disabilities should not be considered as special users, they are actually the most important users. And to these users, we have a responsibility. It is a great idea to hire a disabled person in order to understand what it’s like to feel like being responsible. It is also a good to prototype a product and test it for special users.
Making users into power users is normally seen as an achievement when only applied to users who don’t have accessibility requirements. Unless your product/service directly talks to special people with disabilities, you can make certain small changes which can improve your outlook.
Let us see the example of building a physical infrastructure e.g. a bar, a shop or a library. If we design and construct it without making it accessible for wheelchair users, it puts a lot of mental strain, and nervous tension, to these people. Once I went to an Embassy, and I had a pram with my two months child in it. The complete application processing unit from tickets, to photos-taking, and to document handling, was in the basement. But the basement had the only staircase without the wheelchair access. This thing stuck in my mind and remained there for quite some time. Unless it is fixed, a user with a wheelchair will either need to be carried to the basement or paperwork will have to be brought up to him which will not only cause a hassle to him but to the staff attending him causing long hours for the work to be accomplished.
From above example, you can assess how important it is for any organization to think about accessibility, and why they should feel responsible.
Assessment of assistive technologies
We need to know the approximate number of assistive technologies. Assistive technology does not mean that it can only be used by a disabled person. It can be for anyone who needs something to achieve something. So given this teeny tiny information, we can come to a conclusion that UX is mostly about ease of use. Wheelchair, spectacles, sunglasses, pram, jogging shoes, etc all come under the wide definition of assistive technologies. So it would be great that we evolve and think UX accessibility in these generic terms. Another aspect of assessment is that you ask those users who are the family members or friends of the users you are checking accessibility against.
Designing for Accessibility
To a lot of us, designing for accessibility might seem like a mammoth task. But as stated above, it is just like designing for users all over the world. In EU, designing for accessibility is not just optional but mandatory by the law. In this article, let us explore a few areas of accessibility:
Visual impairment may come in any form. It can be color blindness, long and short sightedness, partial blindness (against dark colors) etc or complete visual impairment. When we say designing for visual users, we consider all the above types. For example: for users with complete visual impairment, we might incorporate a speech software and a Braille keyboard that will allow the user to interact with the application. For long sightedness, we can incorporate an option to increase the size of the text. Background colors can be chosen that will allow a color blind user to work through the application.
Some people get epileptic attacks due to flash on the screen or due to flash photography. This is one of the very important consideration that you have to make in certain products. E.g. if you are running a TV channel and you care of this audience as well, then you have to mention before the transmission of flash photography that the images or the footage contains flash photography.
There are certain users who are completely color blind. One such example is of Neil Harbisson. He is an artist and was born completely blind. He is now using a device through which he can hear colors in his head. Well, how does it is possible, see for yourself in this TED talk.
The relevant controls and the trigger to those controls are the keys to successful product/service journey for all users.
As the name suggests, users with lack or limited use of motor sensors. While it might be difficult to incorporate amputated or ones that do not have limbs, we can see the example of Stephen Hawkins who has a special wheelchair with sensory software that allows him to navigate and even give lectures using special software to process his thoughts and convert them into words. Given this example, it might look like that it is quite expensive to cater for such users at a scale. It is an active area of research as well. So it would be great that you participate in such research so that you might find simple ways to address such complex audience.
Any auditory disability i.e. partial or full hearing impairment needs to have special conditions in place in case the product that you have designed requires using sounds or has speech incorporated.
These types of disabilities are quite common. As I say this, it also means that we might have more solutions for this kind of disability. A person who is not tech savvy should have the option for a walkthrough or tutorial or training for using the product. People with dyslexia can also have trouble using your product or application. A speech software might help.
In similar ways, a lot of disabilities can be categorized. However, a point to note here is that not all disabilities can be solved using accessibility. People with multiple disabilities can even be harder to incorporate. For them, a specialized version of the product might be needed. Solving accessibility issues can be expensive and for products, with a small budget, it might not be easy to incorporate accessibility issues. However, assessment of a project based on case to case and to marginalize the problem may help decide which special issues can be catered.
Products from Amazon.co.uk
Price: Out of stock
Price: Check on Amazon
Price: Out of stock
Price: Check on Amazon
Price: Check on Amazon
Some people might have short-term memory loss. To cater to the possibility of such a scenario, you need to make certain adjustments in particular if you are running a web platform. One such example is to always use the history or contextual information about the user, and use that information if user tells you to show it.
Web Content Accessibility Guidelines (WCAG) (Section 508 Conformance)
Let’s come to Web, and in particular the Web Accessibility Testing. We have noted that many websites claim that they conform to WCAG. But what actually they are claiming is actually the automated tests which were run on the code and not the actual user interfacing testing (getting feedback from the actual users and putting it in the product lifecycle). So here is a way that you can craft your own UX for accessibility.
Our own best practices
Always consider accessibility requirements from the start of your project. Research what are development practices specifically what are the modern ones. Use a language which is easy to understand e.g. active voice instead of passive voice. Always choose technologies which have user rankings. And when doing the research, testing, or roll out always include people for whom you are designing the product. A one to one relationship during your research will yield a proper workflow for your future designs. In the case of the web, you can employ already existing browsers extensions as well OR you can provide your own on top of other platforms. E.g. Stylish extension for Firefox and Chrome. Also apply all the relevant WCAG 2.0 standards as well. Make the assessment of UX team as well. E.g. ask the quality testing team to do an in-depth analysis of UX teams from time to time.
In conclusion, it is really difficult to do, but achievable so challenge yourself and do it right. Make sure you understand your audience. Always use feedback. Ask questions and be near to the users. And make accessibility the core of your design instead of making it optional.