Panel discussion between 4 people that occurred on stage at the end of the event.

Findings and reflexions from Accessibility Club Summit 2019

MarCo
Goodpatch Global

--

This year, I was pleased to attend the Accessibility Club Summit (ACS) in Berlin. I attended this conference to deepen my exploration of the topic of accessibility and inclusive design. For those who may be new to the subject, “accessibility is the degree to which a service (physical or digital) is usable by as many people as possible” (source: Laura Kalbag). While inclusive design “is a design process in which a product, service or environment is optimized for a specific user with specific needs (source: Wikipedia).

Here is a summary of the points I found the most interesting that were discussed at ACS.

Everything can be designed to be inclusive.

Increased awareness about what inclusivity means coupled with publications of guidelines and tools, has resulted in accessibility becoming more and more integrated in programming and design patterns. As Sergei Kriger demonstrated in his talk “Drag & Drop components for blind users? Are you kidding me?”, whether you rely on native UI components that are designed to be accessible, or you create custom components for specifics needs, there is always a way to make those components more accessible. Even for complex interactions such as sliding for filtering, sorting tasks or drag and dropping an image in your browser, solutions exist for developers with semantic HTML or ARIA for custom components. In that case, designers should not forget that it is also their role to design these accessible features.

To find out more on how to use semantic HTML and ARIA, I recommend reading “Why, How, and When to Use Semantic HTML and ARIA” by Adam Silver.

Sergei Kriger presenting the example of omio website with a price range filter as a slider one has to drag and drop.
Sergei Kriger explaining how to design and code sliders, so that people relying on technologies such as screen readers can easily book a train ticket, for instance.

Rationalising accessibility issues is key to improving your product in the long run.

It is painful to admit, but since lots of digital products rely on sprints and pipelines, one has to first prioritize an accessibility bug to actually improve the overall experience. “What is the most important criteria to estimate your product usability,” asked Sarah Brodwall. In her talk “Pulling the lever: Real-world prioritization of accessibility issues”, she described the ingredients required to rank issues (and not people): assert the level of the barrier your issue is creating, the impact it has on your target audience, and the effort it will cost you and your team to implement a solution. By balancing these criteria correctly, you are able to obtain a contextual, practical pipeline helping you identify which issue you should work on first. Accessible products don’t come easy: They are something to aim for in the long run, but we have to start somewhere.

A night mode for an insurance website is useful, but the barrier might not be as important as for other type of product.
A night mode for a sleep tracking app might very useful because the context of use (at night) makes it a bigger barrier.
Sarah Brodwall demonstrating how she prioritizes accessibility features for product pipelines. In this example, a night mode for an insurance company website is less urgent than designing it for a sleep tracking app.

You are responsible for what you create.

Let’s face it; going the extra mile toward inclusive and accessible products will require a shift in your company culture. It requires time, money and dedication from both you and your company. In her talk,A11y — from ‘whaaaat?’ to a core part of dev team’s workflow,” Anna Karon shared her path to include accessibility as a key component of her company culture. The important steps she took include research, raising awareness in her company through internal talks and by sharing resources, including tools such as WAVE, Axe and accessibility focussed linters in testing processes. Anna was also able to create an open source project focused on accessibility and invited people with disabilities to perform usability tests. Someone has to take accountability for this topic in a company. What if this person was you?

Anna Karon explaining on stage that UX/UI designers are the first people that should care for accessibility in a web project.
Anna Karon showing us where thinking about accessibility should start in a (web) project workflow. And guess what dear designers? We are #1.

Never stop questioning the norms.

Accessibility is much more complex than a simple checklist of rules to follow. While it is, of course, important to integrate accessibility checks into your design/development process, as Vasilis van Gemert stated in his talk “Exclusive design” there is a lot of room for improvement toward the design of assistive technologies. Screen readers for example, can deliver a huge amount of information that might not always be useful for the end users. For instance, they can state the HTML landmarks. This is useful to help people understand where they are, but only if they understand what landmarks are. What about people who don’t do programming?

Vasilis van Gemert standing up, surrounded by his audience, talking about the design of assistive technology.
Vasilis van Gemert questioning his audience during a barcamp session about the current state of assistive technologies.

As a conclusion

I would like to say that I am particularly thankful to the team who organised this year’s ACS. The day was thoughtful, well-organised, and was a very important and insightful experience for me. I’m already looking forward to the Accessibility Club Summit 2020.

With the conference badging system, you could say if you want to engage a conversation with strangers or not.
Joschi Kuphal, one of ACS’ organisers, explaining their thoughtful, simply inclusive and welcoming system of badging. ❤

--

--

MarCo
Goodpatch Global

Interaction designer specialising in accessibility @DigitalService