Accessibility Guidelines
For InVision Ag accessibility came up when a customer asked about the guidelines and norm we use to develop our software. So we started the journey towards accessibility and discovered which guidelines exist and how we can design and implement accessible software.
In the end we developed what needed to be improved within the existing software and how we can improve our way to deliver more accessible software in the future. My role as UX designer was to create the guidelines and support the teams to develop software according to the guidelines.
Accessibility = Disability? What is it about?
Being accessible for a company often means, that the product or service provided can be used by people with disabilities. During my research I recognized, that it is more about inclusive design than the usability of a product for certain people.
If we take a look at people with disabilities we often think of humans with personal health conditions. But if we look further we can see: “disability = mismatched human interaction” as it is stated in the microsoft inclusive toolkit.
The persona spectrum from the toolkit even makes it clearer: Everyone can be disabled in various scenarios.
Imagine that you are in the office, just catching a coffee in between meetings. With your hands full with the delicious cup of coffee and your notebook, you finally arrive at the meeting door. But you just can’t open it with your hands full of stuff. This is frustrating. Isn’t it? I learned during research that everyone easily can find themselves in a scenario where mismatched human interaction is just happening without being recognized.
Accessible products or services are the end result, we should start to think about inclusiveness when designing and implementing software.
Make a start
First we just wanted to deliver a solution to our customers to make them happy. I soon recognized, to aim for a modern user centered product, we needed to start our journey towards inclusiveness right now.
Our constraints
- complex software grown since 1995
- low awareness about accessibility within development teams
Our requirements
- become more accessible to enable a broader range of customers using our software (e.g. public services due to EN 301 549 or federal agencies due to section 508)
- integrate the extra work into the existing workflow
- no extra ressources for implementation available
- integration in the current projects is necessary
- teach the teams how to develop accessible products with low effort on each side
Outcomes and achievements
Our solution in the end was a package that provides several touch points for different functions that supports design and developers to understand accessibility and helps them to deliver accessible software.
- design system abstract including a designer and developer checklist
- using automated tests and supportive tools
- accessibility audits for teams
Design system abstract
We do have a design system in place including UX guidelines and informations about our CI. The accessibility guideline page in this design system, includes the guidelines linked to the relevant WCAG principles, we choose in detail. As well as a checklist with actions and recommend tools for designers and developers. This checklist shows actions they can take during any phase of development for a better software.
Automated tests and supportive tools
Test the product
axe for chrome runs tests that informs you about critical to minor issues in the web app.
For designers
To start with inclusive design means asking how our designs affects interactions and create mismatches (e.g. by in which scenario do users interact with product or service).
There are several websites and extensions for chrome, sketch and figma to check the contrast ratio. They are really easy to use and they have a huge impact on the accessibility of the product. You can give it a try here.
Implementing pa11y within our design system helps our designers from the beginning to check the accessibility of their components and fix the main issues.
For developers
There are tools that can be implemented easily to support the developers to deliver accessible code. For example pa11y provides a jenkins integration for automated accessibility testing according to the WCAG.
Audits for teams
Just writing guidelines and providing checklist does not do the trick. I needed to become an evangelist and sometimes advocate for inclusive products. That means to support the teams to use the provided artefacts. I am doing accessibility audits on a regular basis with teams. What we do is sit together, take a look at the part of the software the team is currently working on using the checklist. We discuss the issues, create tickets for the backlog and decide on their criticality for the team and company. Then it is up to the team to start the work.
Next steps
Success stories
Some developers already recognized that inclusive software is not that hard to ship. They turned into evangelists and are using the guidelines and even come up with ideas to improve their workflow. Simplifying the steps for the colleagues helps them to understand why they do it and enables them to deliver inclusive products.
Let’s make it clear
Delivering accessible products or services requires effort. If we decide to start small and work towards accessibility in the future, we will have an inclusive product in the future.
We can’t stop learning about accessibility and inclusive design. For me one part of delivering software is to take the decision, how far you want to go with user centred design, having your company goals in mind.
Responsibilities
For diving into accessibility I needed to build a lot of new knowledge around the topic inclusive design. I needed to understand the whole development cycle.
Main areas of responsibility:
- Discovery (workflows)
- Customer Management (on site visit)
- Writing skills (guidelines)
InVision Ag
