Accessibility is an important part of digital experiences. Unfortunately, it takes time to learn (as I wrote about before) and it’s difficult to do properly which leads to most teams worsening the accessibility of their project when they try to improve it.
To solve those issues, we had a workshop on the topic, which I organized. This made me happy since it allowed me to share the knowledge I spent time researching. I skipped through the general guidelines that we can find on the web, and made a tailored session, based on our past projects, which problems are coming back and how to have a workflow that can solve those.
My process to educate myself on accessibility and create a workshop:
1st - finding a goal
As an agency specializing in creating websites, our main focus is to make our clients happy. Therefore, I went through a few client’s project tenders to find out what their major concerns are, and found out that they’re mostly interested in following legal requirements, which is passing the BITV test (it’s standard for Germany, it is based on the WCA guidelines and the European accessibility laws, you can find out more about it here).
2nd - researching
Now knowing that our main focus is following the BITV standard, I went through their website to find out more. Since nothing is better than practice to learn, I started modifying our portfolio and other projects based on those rules. I spent the most effort on the Figures portfolio since we thought it would be a good project to prove that we have some experience on the topic. The other projects were only for training purposes. Still, it ended up being helpful, since I found which issues occur repetitively through our projects.
This research is useful to find what we need to improve in our process but also to find out how much effort is needed to do so. Indeed some things can be implemented easily or can be mixed with the general effort that we make to improve our projects. On the other hand, some can require additional content and effort from the client or a bigger budget. It’s primordial for us to find that out, to properly plan, and to communicate it with clients before the project starts.
3rd - creating content for the workshop
Based on my findings, I made a list of things I wanted to talk about during the workshop. I focused on what the design team and project management team should change to their workflow (feedback for the developer team was not included as we’re the ones who have been doing the most research on accessibility). I then discussed it with other members of the team who requested a more interactive workshop, with more examples and demonstrating testing methods. I therefore updated the presentation’s content in that direction.
The workshop
Introduction
We made the participants write down the types of disabilities they are aware of and then showed a list of existing disabilities and explained them. Afterward, I introduced the WCA guidelines and the BITV, the difference between them, and why we decided to focus on the BITV test.
Comparing 2 graphics
I then asked our team to compare 2 graphics, which were both created by one of our designers from a past project and write which one is more accessible and why. Most people correctly found that one is better since it does not rely on colors to convey its meaning and the captions are next to the elements they represent. I then introduced the browser extension Web Disability Simulator which allows the simulation of different types of disabilities and went through the website with the color-blind simulator on, to give a better idea of what the website would look like for someone with disabilities.
Navigating a website with tremor
I showed another way of using the Web Disability Simulator extension this time using the Parkinsons simulator, to demonstrate how challenging it can be to navigate if the navigation elements are not big enough and do not have enough margin around them. I also showed the staybl app which was made to cater to users with those needs.
Zooming the website to 200%
For some users, being able to zoom the website is primordial which is why the BITV test requires that the website can still be used normally when the website is zoomed at 200%. Unfortunately, this causes issues with some designs that we often use, which is using a slideshow mechanic, and relying on each “slide” taking the full-screen height, like for our project Wind City. In the future, we might need to either give up on this scrolling mechanic or research if there’s a way to make it more flexible so that the scrolling mechanic changes slightly if the user zooms in and the content would also rearrange itself differently.
Our portfolio website also failed this condition, because of the menu. When the social media submenu is open, it relies on the fact that there’s enough space on the bottom of the screen to display it. When zoomed in to 200%, however, that space is missing for some screen sizes, and because the menu is in a fixed position, it’s not possible to scroll down to see the bottom of the menu. Thankfully, this problem was possible to solve while keeping the original design, by making elements arrange themselves differently if there’s not enough space left in the screen. Still, elements in a sticky or fixed position can generally cause issues for this requirement.
Comparing alt-text descriptions
The next activity concerned images of our projects, where I had 2 different texts for the image description and I asked everyone to vote on which ones they thought was better and write why. There was a mixed result, with a slight preference for the new text description. At this point, it was noticeable that we were towards the end of the workshop because people were questioning whether adjectives like “fascinating” belonged inside of an image description, and if we should not try to simplify everything.
Previous description: “Various articles about the stars and their stories”
New description: “The article overview page shows various articles exploring the human connection to the stars, constellations, and planets in various formats. Users will find more articles that delve into the fascinating world of celestial bodies as they scroll down.”
This exercise was the only one in the workshop where I did not have a perfect answer prepared. The different text descriptions were born out of my reflection on what should a good alternative text be. I believe it needs to serve the same purpose as the images it represents, and since our design team spent quite a bit of time polishing the images to make our projects look good, the alternative text description should also do the same. It’s justified to question whether it would be better to keep the descriptions as simple as possible. But in this case, the rest of the text on the website is also focused on promoting our work, so it only makes sense that the image description would stay consistent with the writing style.
Making everything accessible adds a lot of constraints to projects, this is why there’s also the possibility of creating multiple versions of the same website and letting the user choose at the beginning, or during the use of the website if he/she would prefer to have text in simple language.
All of this additional content requires naturally more work, which is another point that I wanted to address during the workshop: how can we automatize a bit of this process to possibly save time? In this case, the new descriptions were made with the AI assistant provided by Bing. You can read more about this process here.
Judging interactive styles
The next exercise is comparing interactive styles made in our previous projects. I created this one with a 2nd goal in mind: creating a list of interactive styles that worked well in our previous projects. Indeed, to make a good interactive style, the new style should be noticeable and not rely on color. This is something that should be improved on our project, and giving feedback about it in the past has been unsuccessful. I think the main issue is that interactive styles are often an afterthought since we don’t present them to the client during the design process. I am hoping that having a list of quality options to choose from will help with that.
Guessing what the elements do
In this exercise, I wanted to highlight both the inconsistency problem with interactive styles throughout the project. The header, footer, text, and rest of the content are often treated like separate groups, with different style guidelines. This can be confusing for users since they have a hard time knowing what will happen when they click on an element, or if this element is interactive at all.
The 2nd highlight of this exercise is one of the designs which has icons inside of it. This makes it easy to understand that the button downloads something, leads to a new page, or shows more elements. Another great side of this design is that it’s easy to create animations for those icons, which are great for interactive styles that are both aesthetically pleasing and accessible.
Finding accessibility mistakes in our portfolio
This final exercise allows the workshop’s participants to apply the knowledge they just learned. It also is a great opportunity to demonstrate testing tools. I, therefore, talked about how Lighthouse is great for detecting accessibility errors that are not found easily with manual testing. WAVE can also be used during the testing, as well as Web Disability Simulator. Then I showed how to customize the browser’s settings to change the default colors and font size of the website, and the issues it can cause.
Finally, setting goals
After the end of the workshop, we talked about future goals and a timeline to improve accessibility. Those goals include talking with clients to see which aspects of accessibility they would be the most interested in (since making a website 100% BITV compliant adds a lot to the workload, which clients are not necessarily aware of when they plan their budget and the amount of effort they want to put in the website). With this, we can further prioritize how we want the team to improve and this would also help plan the content for the accessibility statement page of the portfolio website.
In Europe, websites complying with accessibility laws need to have an accessibility statement page explaining the current stand on the website on accessibility and what is planned to improve it. We would like to spend some time planning the content and design for it as it is a great medium to communicate which improvements were made on the website and the accessibility knowledge and services we can provide.