Building for Everyone, a discussion with Google Developer Group Mons

This is a summary of the Google Developer Group Mons’ event on accessible web development: Building for Everyone, where Julia UndeutschEmma Dawson, and I discussed our experiences advocating and working in the digital inclusion space. Join us through space and time and check out the space recording of Building for Everyone!

How can companies ensure that their products are accessible?

Julia talked us through her process for assessing existing accessibility knowledge whenever she joins a new team for a project. The designer is the key person here because they are building the blueprints for the entire product. This is why designers must be knowledgeable in web accessibility and annotate expected behaviors in their designs, so developers don't have to guess.

What's the main argument to use to convince the company to make products accessible?

Emma said it best: If you think you can't afford accessibility in your project at the beginning, you definitely can't afford to retrofit it. For most companies, the cost and legislative arguments still hit harder than the human-centered ones, but let's not forget that building for everyone is simply the right thing to do.

But again, if that doesn’t hit, hit ‘em with these:

Do all projects need to include accessibility?

Yes. Period.

We know it can be overwhelming to look at the WCAG in its entirety, but your target demographic can be an indicator of where to start. Think about what types of disabilities are most common in your audience and what adjustments would be needed.

For example: If you have a nutrition-tracking service, you might very well have users with type 2 diabetes. Diabetes can lead to a variety of complications, including eye problems from diabetic retinopathy, or nerve damage. Hence, starting with adjustments for low vision and motor impairments would be a solid choice. This type of critical thinking exercise can give you a starting point, and from there on you can continue your research.

When can a developer consider a project as successfully inclusive?

We all agreed that project teams need to let go of the myth of "100% accessible" and start iterating on it instead. No standard can tell you what "fully accessible" is. The more you learn about disabilities, the more issues you will grow aware of. Yes, that will be frustrating at times. But we are learning more and more about disabilities and developing new assistive tech every year. There are always new aspects and facets to learn, so the best thing you can do is try your goddamn best with everything you produce, every line of code you ship to production, and every document you convert to PDF.

Empathizing can only take you so far, so look towards creators with disabilities to learn more about accessibility. People who live with colorblindness 24/7 are indefinitely better judges than any color contrast checker tools. This might be the UX researcher in me speaking, but the final judges of your product will be the people who (want to) use it.

Recording and Timestamps

4:10 Space introduction by Thierry & Julia
7:00 Personal experiences from JuliaLaura, and Emma
16:30 How can companies ensure that their products are accessible to people with disabilities?
19:30 Main argument to use to convince the company to make products accessible.
25:25 Do all products need to be inclusive?
30:40 How can we balance design, functionality, and accessibility in development?
44:00 Do companies follow accessibility by design?
51:00 When is a product considered accessible?
57:45 How to test for accessibility? Any tool recommendations?
1:03:15 Outro

Next
Next

Sign Language in K-Pop