Sometimes it was about color contrast, sometimes about Leichte Sprache (a German concept similar to Easy read), sometimes about the headline structure on a website: accessibility has been popping up in our projects for quite a while now. Too often, though, requirements came up late in the process – usually paired with uncertainty on the client side and, to be honest, on our side too.
That’s why, starting last fall, we began sitting down together regularly – with the goal of understanding accessibility better and anchoring it in our workflows. Here are a few thoughts that stuck with us along the way.
Accessibility forces good practice in design, code, and content
At its core, accessibility is about making sure as many people as possible can use digital products comfortably and meaningfully. Which is actually a fantastic idea – both for users and for website owners who want to reach more people.
We started with qualification in the team: we took Sara Soueidan’s excellent crash course and established an a11y weekly. At the same time, a Figma board started filling up with screenshots of old website components that didn’t look so great when tested with screen readers or contrast checkers.
The positive takeaway: in many cases, accessibility requirements are really just good digital product practice. They’re about clear content and design, and solid semantic code. Sometimes it’s also about simplifying things overall – like ditching the multimedia slider in favor of a format that works for everyone.
Building accessibility in from the start: components in the bruesource wireframing kit with relevant a11y annotations in dev mode.
Accessibility is often a cross-discipline topic – requiring expertise in content, design, and development. In practice, we found that accessibility requirements pop up at every step of our digital process: from scoping and information architecture, through UI/UX design, development, and content production, to testing, handoff, and additional workshops with clients..
bruesource toolbox: wireframing kit & frontend component library
In new projects, we now place an accessibility briefing module right at the beginning of the process – alongside clarifying the technical framework. This way, requirements can be considered earlier, and clients can be better prepared and included. That’s important, since editorial teams often face big tasks too, like creating subtitles or new scripts for videos, or writing alt text for images and graphics.
The starting point for the website concept is our updated bruesource wireframing kit in Figma, which contains a set of vetted standard components. Information about element hierarchy, focus order, or content for alt text and ARIA labels is already included (our starting point here was the very well-documented a11y annotation kit).
On the dev side, this is paired with the bruesource frontend component library, a thoroughly tested set of unstyled frontend modules that structurally match the components in the wireframing kit.
Meow: Modules in the bruesource frontend component library.
The idea is to create a smoother handoff between wireframes, visual prototypes, and development. At the same time, the visual design of the components remains flexible – since styling can be tailored to each project. Custom components are also possible, of course, though they do come with extra testing overhead.
Workshops and exchange
Recently, we’ve had the chance to audit and improve a few existing websites – and to implement several projects based on the new toolbox. We’re currently developing some basic workshops for clients to help with website handoffs – or with creating accessible documents. In the blog, you’ll also find a first intro to accessibility for product owners and project managers on the client side.
We’re still learning every day. If you’re deep into accessibility, have a special focus area, do testing, or build accessible products yourself – drop us a line, we’d love to connect. You can also sign up for our newsletter, where we occasionally share what we’ve been working on.