10 Accessibility Testing Issues in Responsive Web

What is Accessibility Testing?

Accessibility testing is about testing the whole system wisely in order to determine if people with disabilities will be able to use the system in question or not. Disabilities include a wide range of physical problems, including learning issues as well as difficulties with sight, hearing and movement. This also includes users with weak communication skills or users who are often computer illiterate and autistic patients. The aim is to make technology accessible to both able and disable individuals.

What does Responsive Web Design have to do with Accessibility?

Responsive web design (RWD) is an approach aiming web design to have flexible web page layouts and optimal viewing leading to easy reading and navigation across different-sized devices. Non Fluid sized screens used to cause overlapping or cut off text when a web page is resized, which was a barrier for users having low vision. Responsive design principles, including fluid layouts; benefit users with disabilities on desktops as well as on mobile devices.

Accessibility Testing issues found in Responsive Web

I discovered some issues while working on accessibility testing projects .They are listed below:

• VoiceOver usually doesn’t speak from labels correctly in Mobile Safari and even the words for example “ADD NEW FRAME”. It reads out “ADD” like it is an abbreviation. Although in the project context that meant to add a new frame. Even while swiping, it misses <iframe> elements and it loses its focus on elements most of the time.

• VoiceOver sometimes doesn’t say data table row and column headers correctly and there is a chance that data can be missed in the majority. It does not announce row headers as user flicks through the content within a data table.

• Readability, this option determines whether all labels are displaying correctly in the application or not? In one of the apps I tested before, the labels and boundary of a cycle was of very light color that even a magnifying glass was of no help.

• Users with low vision, light sensitivity, dyslexia and color blindness find it difficult to access sites with dull colors. A high contrast mode should be turned on to highlight the text against a dark background.

• It is always better to ask whether highlighting with inverted colors is viewable to users with low vision or not. Testing of color in the application should be conducted by changing the contrast ratio.

• Once I came across a case where an app became inaccessible after logging off and the ‘voice over’ didn’t inform about the session that expired on the device.

• When a user clicks occasionally on the back button on a mobile device, VoiceOver never tells on which screen it is leading us most of the time. This was widely reported in loss.

• The text must be readable and understandable when user switches the device from vertical to landscape mode. The application based on accessibility must help users avoid any bugs.

• In one case, a tester clicked on a phone field for registration form to enter a numeric value. VoiceOver did announce the numeric value which the user typed from the keyboard but when the tester revisited after an hour the phone field didn’t revise the number entered before. A visually impaired person won’t be able to know the number.

• The use of hotspot (widget) and navigation in one of the applications is reported less for autistic patients which could pose a hurdle for such users.

Above were some of the issues I faced during accessibility testing. Please feel free to share your experience too. 🙂