Over the last two decades, the web has seen continuous, progressive and rapid improvements. From the days of static web applications, interactive applications, through responsive web applications and now developing accessible web applications.

This article is entirely focused on Accessible Web Application (AWA); it is indeed fascinating how the web has transitioned to ensure that content on the web are available to different types of users. On 5 May 1999, Web Content Accessibility Guidelines (WCAG) was adapted as a World Wide Web Consortium (W3C) recommended documentation. Wikipedia describes W3C as the main international standards organization for the World Wide Web (abbreviated WWW or W3). For any Web Technology seeking to render content on the Web, it is essential to conform to guidelines and standards. These standards are borne out of empirical research. W3C also engages in education, outreaches and develops software that serves as an open forum for discussions about the Web.

Accessible Web Applications also known as A11y is the design of web applications for use by everyone. By everyone, we simply mean that web applications are fully designed for both sighted and non-sighted users as well as people with hearing, cognitive and neurological challenges.

People with disability form about 10% to 15% of the world population, according to the World Health Organization (WHO) report – https://www.who.int/disabilities/world_report/2011/report/en/

Non-sighted users range from the group of people with colour blindness to people who are fully blind. This particular group of users have challenges understanding image content that do not have text description of what exactly the image is about. For most websites that seek to provide text description, the descriptions are most often not in correlation with the content in the image.  Clearly, without text description this user has no way of appreciating what the image is about. Users with colour blindness may also have difficulties in appreciating the image content. Most often, a web application with visual effect are completely a mess when it comes to reading the content on the website with screen readers that are embedded in most browsers.

Users with hearing impairment unlike users with visual impairment have absolutely no way of understanding content that are communicated through sound. For this category of users, Developers are mostly conscious and they design applications with this category of people in mind.

Web Applications with overly complex designs, distractive repetitive animation and navigations with completely inconsistent patterns appearing as glazed for some users have proven to pose problems with their inaccessibility to users with Cognitive Neurological Challenges. Getting a hand over information on overly complex web application with irregular content structuring on the website can be a great challenge for users with Cognitive Neurological Challenges.

For the past decades, Web Application Developers design applications for the visual impact it may have on users, neglecting users without the capability to visualize web contents. As digitization sweeps over and driven by automation, there is the need, essentially to ensure that Developers write codes that allow assistive technology to interpret web pages.  This conscious effort on the part of the Developers are necessary to ensure web contents rendered are accessibility friendly.

Note the following definitions:

  • Code Review is simply the mechanism of reviewing the code written by a Developer or an Engineer.
  • DevOps is a set of practices that combines software development (Dev) and information-technology operations (Ops) which aims to shorten the systems development life cycle and provide continuous delivery with high software quality. https://en.wikipedia.org/wiki/DevOps

In a structured DevOps community or work space where code review is a central and critical part of Web Application Development, for work spaces without code reviewers it is essential to establish a mechanism to peer review codes written by peers. Peer review means, a Developer reviewing the code written by another Developer within the same workspace. Peer review is mostly effective if the culture of developing Accessible Web Applications are strongly grounded in the Developers within the same workspace. Without such knowledge base, it is practically ineffective to review code. The question arises: are you reviewing the code without ensuring the codes support Assistive Technology?

 https://www.w3.org/WAI/intro/wcag provided a more detailed standards and guidelines for writing codes that support Web Accessibility.

Let us do a demo of Accessibility in action:

Fig. 1.0.1

The Code above (Fig. 1.0.1) is a Form Object with an input field, notice “Name”.  The Code written above is very acceptable if the users are visually sighted only.

Fig. 1.0.2

 The Code above (Fig. 1.0.2) is also a Form Object with an input field, notice this time around there is a “Label”. The Label tag coupled with “htmlFor” provides and allows assistive technology to interpret content for non-sighted users.

As discussed in this article, understanding the standards and guidelines elicited by W3C documentations is the first step for knowing and understanding how to write codes and develop web applications for everyone that leverages on assistive technologies, without which the World Wide Web would definitely be a daunting place for people or users with different segregation of disabilities. In the spirit of creating awareness, thank you for reading.

Author: Patrick Wunake (Member, Institute of ICT Professionals, Ghana)

For comments, contact author pmarks1914@gmail.com  or Mobile: +233 272068039