In the digital age, the web has become an indispensable part of our lives, providing a gateway to information, communication, and opportunities like never before. However, as we strive for inclusivity and equality, it is crucial to recognize that not all individuals navigate the online realm in the same way. This is where web accessibility design and testing come into play, ensuring that websites and web applications are usable and enjoyable for everyone, regardless of their abilities or disabilities. In this blog post, we will explore the significance of web accessibility and delve into the best practices of design and testing, empowering you to create online experiences that leave no one behind.
Why web accessibility is important
There are several standards to meet when it comes to building an accessible website. These standards exist to help us developers ensure our products are easy to navigate and meet the needs of a broad range of users. In the end, investing time and effort into meeting these standards can help attract new and more pleased customers, which can have a positive impact on both revenue and brand sentiment.
Let’s keep in mind that there are a number of ways to make our websites more accessible. Some of these include adding alt text to images, providing transcripts for audio or video content, and using concise and clear language. In the following sections, we’ll look deeper into a handful of web accessibility design and testing best practices. Following these, we can make sure our digital products are appealing and helpful to as many people as possible.
What is web accessibility design?
When it comes to ensuring accessibility across our websites and web apps, a good place to start is with web content design. Accessible design should consider several various attributes, such as age, economic situation, geographic location, language, race, and gender, among many others. Accessible design should be driven by a conscious understanding of user backgrounds and capabilities. It’s important to keep in mind that digital interfaces that focus on inclusive design can positively impact the user experience by promoting a wider sense of belonging.
There are 2 concepts worth mentioning here: Universal Design and Inclusive Design. Both of them aim to reduce barriers between users and technology and create inclusive experiences, but are distinguished by the following characteristics:
• Universal design focuses on creating an experience that can be accessed and used by the greatest extent of people. Far apart from inclusive design, universal design enforces a single design solution without the need for adaptations or specialized design.
• Inclusive design accepts and embraces multiple design variations as long as they achieve the desired results. For these reasons, universal design is more widely used compared to inclusive design, which is applied more often to digital product design because it’s relatively cheaper and easier to adapt such interfaces.
Small changes can achieve great results
If we think about a user population of elderly people or those with visual disabilities, text legibility and dark mode can make a big difference. From this point of view, designers must think about using reasonably large font sizes, having high contrast between characters in the foreground and background, and using a clean, easily legible font. Such features are important to all users but are particularly important considerations for elderly users and those who may face challenges with interfaces with poor legibility.
Web Content Accessibility Guidelines (WCAG)
In order to have a standardized way to determine if a website complies with accessibility, the World Wide Web Consortium (W3C) recommends adhering to a number of ground rules recognized internationally and compiled in what is known as the Web Content Accessibility Guidelines (WCAG).
The first version of this document was published in 1999 as WCAG 1.0. In 2008, the WCAG 2.0 was released and remains today as the world standard. Nevertheless, a new update was released in 2018 called WCAG 2.1, including everything from WCAG 2.0 in addition to support for web content and mobile devices using the same terminology for both versions.
The WCAG is separated into three sections:
• Guidelines: This section includes short statements providing guidance on what should be considered by designers and developers to make a website accessible
• Design principles: Includes the four overarching principles of accessible website development: perceivable, operable, understandable, and robust (POUR)
• Success criteria: Contains specific technical requirements to ensure that a website is compliant with the standard
Let’s take a closer look at each one of these sections in more detail, starting with the guidelines establishing twelve rules or requirements.
1.1 Provide text alternatives for any non-text content so that it can be changed into other forms people may need, such as large print, Braille, speech, symbols, or simpler language.
1.2 Provide alternatives for time-based media.
1.3 Create content that can be presented in different ways (for example, simpler layout) without losing information or structure.
1.4 Make it easier for users to see and hear content including separating foreground from background.
2.1 Make all functionality available from a keyboard.
2.2 Provide users enough time to read and use content.
2.3 Do not design content in a way that is known to cause seizures.
2.4 Provide ways to help users navigate, find content, and determine where they are.
3.1 Make text content readable and understandable.
3.2 Make Web pages appear and operate in predictable ways.
3.3 Help users avoid and correct mistakes.
4.1 Maximize compatibility with current and future user agents, including assistive technologies.
WCAG Design Principles
To ensure that your organization complies with the WCAG standards, it must follow the four POUR design principles:
• Perceivable: Information and user interface components must be presentable to users in ways they can perceive.
• Operable: User interface components and navigation must be operable.
• Understandable: Information and the operation of the user interface must be understandable.
• Robust: Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.
WCAG Success Criteria
To achieve WCAG compliance, W3C has broken up the success criteria into three different implementation levels. These levels are known as Level A, AA, and AAA respectively.
In the original WCAG standard, W3C described the differences between the levels as follows:
Priority 1: A Web content developer must satisfy this checkpoint. Otherwise, one or more groups will find it impossible to access information in the document. Satisfying this checkpoint is a basic requirement for some groups to be able to use Web documents.
Priority 2: A Web content developer should satisfy this checkpoint. Otherwise, one or more groups will find it difficult to access information in the document. Satisfying this checkpoint will remove significant barriers to accessing Web documents.
Priority 3: A Web content developer may address this checkpoint. Otherwise, one or more groups will find it somewhat difficult to access information in the document. Satisfying this checkpoint will improve access to Web documents.
So basically, if the first point was achieved this would meet Level A, if both the first and second points were achieved it would meet Level AA, and if all three were achieved it would meet Level AAA.
Web Accessibility Testing
In order to ensure that your web applications comply correctly with the WCAG standards, accessibility testing focuses on understanding how well digital content adheres to these established standards for people who have disabilities. It’s important that accessibility testing be an essential component of usability testing.
While performing accessibility testing, the product is assessed to determine how well it meets the needs of users with disabilities. Some examples of content that is commonly tested for accessibility compliance include email, electronic documents, social media posts, web applications, and websites.
When it comes to accessibility testing, it can be automated with software tools, performed manually, or even by applying a hybrid approach that uses both automated test tools and manual methodologies. From this perspective, a website could be evaluated for criteria such as how well pages have been optimized for screen readers with features like adequate color contrast, appropriate use of white space, introducing alt text, including video transcripts, and proper readability levels.
Automated Accessibility Testing
From a testing perspective, automation is always desirable since once created, a test suite can be run over and over again without adding additional costs to the project. They are also much faster than manual tests by reducing the time to run repetitive tests from days to hours, faster time to market, reusability of automated tests, and higher overall test coverage, just to mention a few benefits.
Automated accessibility testing examples and tools:
A great candidate for automated accessibility testing is regression testing, as it provides a good way to save on the costs of the testing execution by eliminating most of the manual testing efforts and resources invested in the process.
For automated accessibility testing early in the development life cycle, you can always examine generic accessibility testing libraries for different platforms, such as Android, iOS, and HTML that provide a set of acceptance tests for accessibility.
Within the build process, you can integrate tools like axe-core, jsx-a11y, Lighthouse Audits, or AccessLint.js into your project to programmatically add accessibility tests and catch errors as you build out your website.
In your projects, you can always think about integrating open-source and licensed automation frameworks into the continuous integration pipeline. A good practice is to merge into the main branch only if the commit passes accessibility checks first. For the web, you can use something like Deque’s axe-core. For iOS, a good example of a tool you can implement is Google’s Toolbox for Accessibility (GTXiLib); and for Android, you can use Google’s Accessibility Test Framework (ATF).
To add another example, we can mention AATT, which stands for Automated Accessibility Testing Tool. This option provides an accessibility API and custom web application for HTML CodeSniffer, Axe, and Chrome developer tool. Using the AATT web application, you can configure test server configurations inside the firewall, and test individual pages.
Manual Accessibility Testing
No doubt the easiest way to initially test your project’s compliance with WCAG is manual accessibility testing. There are different options for manually testing your projects and ensuring they comply with these rules, from adding plugins to your browser to going manually yourself with the Tab key on your keyboard.
Here are some pretty handy tools you can use in your day-to-day testing:
If you’re a Browserstack user, a cool feature you can take advantage of is the Screen Reader which lets you go through your URL content by just adding it to the browser bar and enabling the Screen Reader option. This way, you can manually check the content contained on your website and experience how a person with reduced eyesight or blindness could navigate through it and listen to a description of every feature.
Wave is another good example of an accessibility evaluation tool you can take advantage of to test your website’s compliance with WCAG standards. In my case, I have used it as a Chrome extension. This add-on offers very complete analysis to users in a very graphic way. It marks all the suggested changes on the website itself and provides a visual summary of them.
Axe DevTools, is an accessibility testing tool that also offers its users a browser extension to analyze their websites. The add-on version provides an option for the user to test compliance with WCAG by providing a scan through the site.
In this case, you open it on your URL and get a compendium about the issues found, how critical they are, and best practices suggestions.
These are just some of the options available for accessibility testing tools. The best thing you can do is to evaluate the best option to implement on your projects depending on your needs and resources.
To conclude, let’s keep in mind that all companies publishing web content have a shared responsibility to comply with international standards for web accessibility. It is our duty as professionals in the software development industry to create awareness of the importance of being inclusive despite our project’s limitations.
In the end, the main purpose of accessibility is to grant access to people with different capabilities to our sites, systems, and applications. Accessibility must always be part of your project’s design and be considered throughout the entire software development process.