Web accessibility and Testing
It is very important that you consider accessibility from the early stages of the project and during all steps. This extra work will be minimum, especially if you already know the basics about web accessibility.
If you consider accessibility at the end of the project, you will have to come back to fix things that you already thought were nicely done but, guess what, a person with disability cannot use them. Even if you spend months working in the usability of your project, if you ask a blind person to try it and he or she cannot succeed, you are not usable at all, at least for people with disabilities. I am talking about visual, motor, hearing or cognitive disabilities, which is about 20% of the world’s population.
Assuming you consider accessibility, you need to do some testing to prove it
There are some automatic tools to validate web accessibility. However, not all guidelines can be evaluated automatically, so you need to evaluate manually.
Evaluation of web accessibility should start as soon as possible or at least the moment you have a test environment of the website. Do not wait until the end because it will take more time and effort to correct things that may have been corrected from the beginning (especially if you are using the same logic in multiple elements, making the same mistake again and again).
Validation can be done manually and with the help of automatic tools to find errors faster. For example, an automated tool can filter all alternative texts of the images, but only a human can determine whether these texts are equivalent to the images. Some recommendations are:
Tools online to validate websites
Tools to validate color contrast
- Web Accessibility Toolbar (Internet Explorer)
- Jim Thatchers Favelets (Internet Explorer or Chrome)
- Accessibility Evaluation Toolbar (Firefox)
- Juicy Studio Accessibility Toolbar (Firefox)
Once you check the compliance of the standards, you need to do some testing with just the keyboard and a screen reader. Cover your eyes and try it.
First, navigate the home page: header, menu, footer and left or right section.
Then navigate the entire website, search for widgets, accordions, tabpanels, carousel, canvas, svg, forms, etc. and verify the correct navigation and functionality. You can use: Tab, Shift + Tab (to return), arrows, enter, spacebar etc.
Does the screen reader announce everything so you can understand without watching the screen?
Some people with disabilities use just the keyboard to navigate, but some assistive technologies also simulate the effect of the mouse, so make both options available.
I recommend testing at least with two screen readers:
- JAWS screen reader (Windows)
- NVDA screen reader (Windows)
- If you have a Mac, VoiceOver screen reader is already installed
You can use the following combinations:
- JAWS with Internet Explorer
- NVDA with Firefox
- VoiceOver with Safari
It would be great if you have people with disabilities as part of your team so you can be sensitive about the challenges and get constant feedback.
When you test the site, validate at least the following:
- That the elements that should receive focus (links, inputs or buttons), receive focus when you navigate with the keyboard
- That the location of the focus is displayed
- That the screen reader announces labels and text alternatives
- That you can navigate correctly components such as menu and submenu, accordion, tabpanel, carousel, etc.
- You must also verify that the roles and states are announced by the screen reader
- Color contrasts
Once you find accessibility problems, find a way to fix it. Then, test again.
Important: accessibility must be maintained over time, especially on sites that are constantly updated.
In conclusion, accessibility must always be present.
Your extra work will have a positive impact on the lives of others.
The small decisions that you make every day can change the lives of millions.