The design team has been busy ever since half of the design team members attended Beyond Tellerrand conference in Berlin. It was an interesting conference about everything web development related (you can check out our post here) and it was the starting point of the reason why we held the Accessibility Workshop within Small Improvements in the first place.
It’s hard to admit that Small Improvements has not been optimized to be accessible as much as it should be. There could be several reasons why this is so, the main reason being that there’s a lack of knowledge about accessibility in general. As a 6-person design team, we wanted to raise awareness for the issues that we’ve found. This involved the use of different tools such as aXe browser extension for Chrome, color contrast checker, down to the MacOS Voice Over to test screen reader navigation ourselves.
What is accessibility for Small Improvements
As a feedback platform, it is important for us that every user of Small Improvements can easily use the tool, even those who use assistive technologies.
Preparing for the workshop
We compiled all of the issues in a Trello board and began developing small work packages that a small team of 2 can take. It’s easy to give a short presentation about accessibility, let the developers explore on their own and call it a day, but that will neither be productive nor exciting. So we included a description of the issue, links to references, best practices and maintainability. These didn’t mean that we knew what the solution was, but it only served as a guide to help them get started and not feel lost on such a big topic.
While some of the packages simply involved adding `alt` tags on all images across the application, we felt it was equally important as the other, more challenging packages like, making sure that the success or error announcements in the application are recognized by screen readers.
The big day
The workshop started off with a general introduction about web accessibility, the various factors that influence it, both from the design and development perspective. This was followed by a technical approach to meet A11y requirements and a demonstration of the current state of the application and its compliance with WCAG standards. Finally, we looked at the Praise create modal and demonstrated how it can improve.
We discussed the work packages and spent the rest of the afternoon tackling them. At the end of the day, each team gave a short demo of their findings and fixes.
Take aways
While some work packages are still a work in progress, and others have not actually been explored yet at all, we still consider the workshop a huge success by pushing to production some of the main issues that we’ve discovered.
The following are now read by screen readers:
- Tooltips
- Our custom select dropdown
- Popups that indicate a successful creation of objectives, praise, notes, etc.
- All images now have their respective `alt` attributes (with a bonus lint rule that will prevent it from happening again)
We all learned something new and the fact that we took the first step to fixing the areas in the application where people using assistive technologies would definitely benefit from, is already an achievement on its own.
