Accessibility testing can seem like an impenetrable discipline at times. Many software developers, web designers and engineers find themselves stuck at this critical phase, with no real sense of how to test it properly. This has resulted in some of the more powerful software out there being very hard to master, or a great many good ideas never getting far off the runway. Still others fail utterly, their designs being impossible to use.
Contrary to a lot of popular belief, accessibility testing isnât all about accommodating special needs, though those are certainly a component of it. Accessibility has to do with the ease of use and access all users experience when interacting with a design.
This is why accessibility, alongside UI, are the two biggest components of user experience. So, on top of many just not being familiar with the mindset needed to test accessibility, and people being unsure of the nature of the field at its core, itâs perfectly normal to need to seek out some insight to overcome this pitfall.
The first thing to bear in mind with accessibility is handling eye tracking and its effect on initial perception and comprehension. Placement of things in certain locations, with certain aesthetic tweaks to draw orderly attention to them, allows a user to naturally deduce what a lot does, or how to get to the basic sections of a design.
Testing this is best handled using mockups and other interactive prototypes, and guiding test subjects to locate various functions easily.
The second thing to test for in accessibility shares its concerns with other aesthetics issues. The right combination of easy-to-read fonts, matching colors, and scale makes it very easy to spot things in the din, which is a problem a lot of websites have.
Now, when it comes to the definition of accessibility pertaining to working with the disabled in mind, itâs probably not practical to gather up a bunch of people in this situation for focus group testing, nor would it be entirely appropriate.
People with poor eye sight, limited mobility or poor hearing who need enhancements via magnification, input simplification or audio enhancement need to be considered, of course. To test these, itâs best to have your testers simulate these hindrances (wearing the wrong prescription of glasses to force inhibited eye sight, etc.) so that you can easily get into their shoes as it were, and know whether or not your design suits their situation or not.
Beyond these things, there really isnât a set of best practices beyond tedious ISO numbers that donât make much sense, and while youâre undoubtedly familiar with those, theyâre not worth really discussing beyond the documents that hold them, of course.
Accessibility testing is important, though, both for the general user base and those who have special needs. Not only is this sound business and design, itâs also very ethically strong to be considerate like this. While itâs hard to wrap your mind around testing for something as somewhat abstract as the concept of accessibility, if you follow these basic ideas, you will succeed. Just, when it comes to the special needs aspect, discretion is the better part of valor.
