The internet or web has become an essential part of our society and lives. Hence, it needs to be inclusive to receive a variety of people, software, hardware, languages, cultures, abilities, and disabilities. Inclusive practice in itself is an approach that recognizes people’s diversity, enabling everyone (including those with special needs or disabilities) to access content and information and fully participate in activities. The vital thing to note here would be “diversity”, “learning”, and “access to information,” and providing this is what web accessibility is all about. Web accessibility enables diverse users (including the disabled) to access web content; hence, it is the inclusive practice of ensuring diversity and promoting universal access to web content and information. It should, however, be noted that it differs from digital inclusion.
The practice of web accessibility is mostly treated as an afterthought in most organizations. This is usually based on the perception (of designers and developers) that everyone can access the web the same way or that only a small population of people with disabilities use the website. However, over 15% of the world’s population living with a disability could affect the way they interact with or access the web.
The burgeoning disability rate has been due to an increase in life expectancy, an aging population, and a global increase in disasters and chronic diseases. In these categories, people may not be able to see, hear, move, or struggle to process some types of information quickly or at all. People who require inclusive practice due to impairment are those who may not have or can use a keyboard or mouse. It also includes those with a text-only screen, a small screen, or even a slow internet connection. Those who may not speak or adequately understand the language in which the document is written, individuals with difficulty reading or comprehending text, etc.
Doing It Right
The key to practicing inclusiveness in providing accessible web content, websites, and applications to people with disabilities is to integrate accessibility early and throughout the design and development process. Besides promoting inclusiveness and increasing the usability of web projects, carrying out accessibility user testing frequently will drastically decrease development costs or eliminate additional costs of accessibility when addressed at the end of the development process. I have also expressed this sentiment in different articles such as:
Failure to address accessibility early by integrating accessibility checks iteratively within the testing and quality assurance (QA) processes will require evaluating the interfaces’ accessibility. This will then mean an accessibility audit of the website and remediating separately to remove barriers after web applications have been launched for public use. Hence, organizations must follow a systematic design process, and that includes addressing accessibility issues at each stage to ensure information and communication technologies are accessible and inclusive.
The international standards organization for the World Wide Web, the World Wide Web Consortium (W3C) in its effort to promote the creation of accessible sites established a working group called the Web Accessibility Initiative (WAI). WAI has gone ahead to create comprehensive guidelines to address accessibility problems and make it possible for web pages to be rendered by assistive technology devices, such as point devices or screen readers. These guidelines are called the Web Content Accessibility Guidelines (WCAG). Three versions currently exist, namely, WCAG 1.0, WCAG 2.0, and WCAG 2.1. Although WCAG 2.0 has been supplanted by WCAG 2.1, the two most recent versions have been considered the official standard and have been referenced in the legislation of many other countries such as in Section 508 of the United States, Australia, Hong Kong, Canada, and adopted in initiatives such as JIS X 8341-3 in Japan, BITV 2.0 in Germany, UNE 139803 in Spain, BS 8878 by the UK, RGAA in France, and EN 301 549 among EU member states.
Web accessibility is not a one-time thing. It is general knowledge that websites can fall out of compliance at any improper update or change. Similarly, organizations cannot regulate who access sites or when a site is accessed. This will then require organizations to ensure websites are inclusive enough to accommodate people with disabilities and continuously ensure the site is accessible at all times. This fact is the only way an organization can be compliant with web accessibility regulations. In other words, incorporating accessibility into the organization’s processes also helps maintain ongoing accessibility compliance.
Even with the existence of WCAG and various techniques for supporting the development of accessible web applications, many organizations still traditionally consider accessibility at the end of the development process. This may be attributed to the preconception that incorporating accessibility criteria in early web development phases may increase cost and development processes. Still, these costs become significantly higher (if we’re humble) when accessibility is taken into account at later stages. Besides, web accessibility is a social issue, and organizations with inclusion efforts that provide an accessible website and application have positioned themselves as committed to providing equal opportunities. This is only one among the many benefits of web accessibility and providing disabled access.
So how do we integrate accessibility into processes? How do we ensure projects take accessibility into account i.e. into agile methods at every stage of the project (initiation, planning, design, procurement, development, closure)?
Project Initiation Stage
Required at the project initiation stage is an understanding of several accessibility considerations such as:
- Legal requirements: Includes accessibility guidelines such as WCAG 2.0/2.1 Level A or AA success criteria, Authoring Tool Accessibility Guidelines (ATAG), User Agent Accessibility Guidelines (UAAG), and Technical specifications such as Accessible Rich Internet Applications (WAI-ARIA), audio and video, accessibility evaluation methods, personalization, etc.
- Analyzing the level of understanding of accessibility across the organization (stakeholders, designers, developers, content providers).
- Training requirements for staff
- Accessibility of tools such as authoring tools.
Planning Stage
It is essential to implement accessibility around designers, developers, and content providers:
- Technical specifications: Software, design and functional design specifications, developer’s checklist, and user acceptance criteria.
- Budget: include accessibility into the budget, funding for accessibility testing, and training.
- Quality plan: include accessibility checks within the quality assurance (QA) control processes.
- Evaluation: establishing the standard accessibility requirements and conformance level, agreeing on a review schedule, and testing for accessibility.
Design Stage
Designer tasks should be checked for conformance to accessibility standards and best practices:
- Initial wireframes: graphic and user interface design (initial wireframes or visual mock-ups) of web pages and applications should be evaluated through early screening by performing checks.
- Content creation: content should be created with people with a broad range of abilities in mind.
Development Stage
It is essential for programming to integrate accessibility from the start of the development cycle:
- Pre-development checklist: a checklist (such as the WCAG checklist created during the planning stage) can be important during the development phase when the product’s implementation begins.
- Development Cycle: The development workflow should focus on accessibility to address accessibility issues immediately. It can also include test iterations of your product with real users.
Project Closure
At the closure of the project:
- Acknowledge accessibility conformance.
- Document the lessons learned in implementing accessibility across stages (can come in handy in the post-project phase and for future projects)
Post Project
A complete, accessible, and compliant product at delivery does not continue to be accessible. Hence, a post-project monitoring plan should be in place:
- Perform periodic checks for continued accessibility.
- Monitor to avoid errors during redesigns or the adding of new features or updates
- Monitor to ensure solutions selected remain current
- Maintain accessibility knowledge of the staff through repeated training since team and responsibilities change.
Conclusion
In a world where the internet and the web have been fully integrated into our lifestyles, web accessibility has come to ensure web content is available to all individuals, regardless of any disabilities or environmental constraints they experience. However, most websites often fail to meet minimum web accessibility requirements, primarily due to the way web accessibility is tackled: accommodation for a minority that can be checked at the end of the website development.
Accessibility should not be postponed until after the website is built. Accessibility integration helps organizations meet and manage the ongoing accessibility requirements, mitigate the risk that may occur due to lawsuits, generally improve efficiency across the life cycle, and provide the necessary support to maintain accessibility compliance with regulations. More so, addressing accessibility at the end of a project is more expensive, complicated, less effective, and time-consuming than when taken into account from the beginning. This is evident in the cost of accessibility testing, evaluation, and remediation while factoring in the time to completion could take months.
A web project should start and end with accessibility in mind rather than considering improvements later as a separate project. This encourages accessibility testing (and accessibility user testing) at the early stages since accessibility troubles are often caused by underlying incorrect markup or compatibility issues. When accessibility is adequately integrated as soon as possible into an organization’s processes and development lifecycle, projects are continuously tested for accessibility, problems are caught and eliminated during the development, and the quality of the product is improved before deployment to the internet. More importantly, designers, developers, and content providers can continue to author inclusive products that accommodate everyone regardless of environmental constraints or disabilities.
