Accessibility: Develop web for all
The power of the web is in its universality. Access by everyone regardless of disability is an essential aspect.
- Tim Berners-Lee
The motivation to write this post has emerged after I attended a panel discussion where the consultants have discussed the statistics of disability and how technology is helping them feel inclusive and more than that to make web a better place by making it more inclusive for everyone.
WCAG has paced up their work in releasing guidelines and criteria of success that’s again a testimonial of how important it is for developer community to create inclusive web. The advent of mobility has strengthen this thought further with new avenues and challenges.
All said and done…What’s in this post ?
I’ll try to be focussed on our choices of tools for the web development. I hope this would help us to keep accessibility as a first class thought during our design and development process. Let’s go ahead and discuss on each step.
Step 1: During requirement capturing
It’s very essential to capture accessibility requirements by creating use cases based on different persona. This helps in creating an inclusive mindset from the very beginning for the team. Asking right questions to the client’s about their inclusivity requirements is the need of the time. This is a nice article discussing quite a few examples of capturing use cases based on different persona’s (Remember accessibility is not just for a visually impaired persona).
Step 2: Working with experience designers
The web page’s layout, content and interactivity needs to be defined by keeping the POUR (Perceivable, Operable, Understandable, and Robust) principles in mind. Here is a snapshot of how WCAG categorise these principles with success criteria required to meet the defined compliance levels.
Tools in rescue of designers:
Here are some tools that could help designers keeping accessibility aspects at check.
Stark: Compatible with almost all major designing tools such as Figma, Sketch, Adobe XD and Google Chrome with built-in support for colour contrast ratio, WCAG compliance levels and visual simulations. This allows the designers to create accessible designs.
http://colorsafe.co/: Allows designers to experiment with colour pallets to choose the appropriate and compliant colours for their designs.
Use of DSL (Design System Language):
Using DSL in the designs is a sensible choice for designers as it helps in creating a consistent application layout. Also it does incorporate design elements that conforms to accessibility aspects as well. It’s a win-win for development teams as well since most DSLs have open source implementations available and ready to use components. Some of the most prominent ones are as listed below:
Microsoft’s Fluent Design System
Step 3: Developer Tools
As the front-end development tech stack is moving fast paced, there are great tools available now to check on accessibility aspects during development cycles. It is important to build a safety net using these tools to make accessible web pages as per WCAG guidelines. Here is a curated list to achieve this.
Axe Toolkit (By Deque)
Deque is a dedicated organisation that works to promote accessibility. They have contributed many tools and library to support development efforts for accessibility. They constantly improves on adding new guidelines support and did provide good configurability options to suit needs of different development projects. They have a pretty good community support too. Here are some featured tool choices.
- Axe Chrome plugin can be used to audit the web pages for accessibility issues. Here is a sample report from Axe Chrome plugin with categorisation so that one can focus on the most important problems identified.
- a11y-addon is a plugin for Storybook based on axe rules. In Component based development, Storybook is a very popular tool for isolated showcase of component’s looks and feel as well as behaviour. A11y-addon helps to identify accessibility issues so that they can be fixed early in the cycle.
- eslint-plugin-jsx-a11y is a plugin that has been built using axe-core to check for accessibility rules as linting checks and provide developers with the most immediate feedback for any misses. It provides many configurations to get the checks for desired compliance. Also typescript support is available with a similar plugin called tslint-react-a11y.
- jest-axe is another great package based on axe-core library that support writing unit test cases to check on violations. This is particularly helpful as it can be baked into the CI pipeline as well that would help enforcing the appropriate practices to eliminate a number of these issues. A sample snippet is here:
import { axe, toHaveNoViolations } from 'jest-axe';import { render, screen } from '@testing-library/react';...test('renders with no accessibility violations', async () => { const { container } = render(<App />); const results = await axe(container); expect(results).toHaveNoViolations();});
- cypress-axe is the available lib to support automation testing for accessibility rules check. Check this article to get more details on how to setup it for automation tests. Again this can be added to the CI pipeline to strengthen the safety net.
Google Lighthouse
Google Lighthouse is yet another popular tool in place to help check multiple aspects of websites including accessibility. It’s available as a chrome extension as well as as-a-service model that can be used in CI pipelines. It provides an assessment score by running some checks on the pages and gives a detailed analysis report as well. Here is a sample score in the report by chrome extension.
WAVE (Web Accessibility Evaluation Tool)
WAVE is an online tool by WebAIM which is another great team doing concentrated efforts on achieving web accessibility. It also providing support via API, chrome and firefox extensions so that their services can be included in the development process as well.
Tools for mobile app development
As mobile devices become a powerful medium to access web, it’s equally important to understand about the tools available to check accessibility aspects on them. It’s possible to create native and hybrid applications as well using the similar web technology stacks.
Are the same tools going to work for mobile ??
Well, partially yes as tools like Google lighthouse can run checks by simulating mobile browsers as well in the development environment itself.
For native applications, iOS provides support to check accessibility features by the accessibility debugger inbuilt into XCODE. Similarly, android development has support through tools like axe-android.
Step 4: Testing strategy
As mentioned earlier, the tools support is readily available and keep getting matured. This is helping to create strong safety net in the mission to produce inclusive and better web. Tools such as Cypress, Pupeteer and Pa11y helps a great deal in building an integrated testing approach. However it is worth mentioning that automation can’t cover it completely.
Formulating a testing strategy that includes manual checks to test if the web product is robust enough and able to render services when used with assistive technologies is also important. It might also help to do a usability test (beta testing) with actual users who are facing impairments. It can give a valuable feedback to improve things further!
At the End..
The objective here is to break the myth that accessibility could be an afterthought and to bring awareness that it could be made a first class citizen easily with the help of available tools similar to how we pay importance to functional aspects of an application.
With a mindset shift to give it the value that it deserved, is just going to make things better for all!
