Ideally we must prevent accessibility issues before they make it to the user. You can call it “shift left” or “start early” or similar, but the main concept is to prevent issues before people design, develop and ship them to users.
One of activities to do so is to check the design before it’s passed to development. It’s especially important when design and development don’t cooperate frequently, so when our work process looks more like a waterfall than something more agile. This is unfortunately still very present – products designed by one part and then implemented by another part. Often with a single hand-over meeting and some limited post-meeting communication.
In such cases it’s even more important that developers get all required information from designers, before they open their code editor. Developers and designers need to agree on a lot – from visual definitions to interaction flows, animations and so on. I’ve often experienced that semantics wasn’t discussed at all, so it felt on the developers. That is the worst imaginable scenario – when developers need to guess what is this piece of user interface according to HTML and ARIA and how will we present it to screen-reader users. Often developers even need to think about color combinations that fail WCAG contrast ratios and even how to make a document outline with heading levels. This shouldn’t be a developers responsibility but should be defined before developers start coding.
67% of all accessibility issues originate in design, according to Deque (opens in new window). This doesn’t mean that designers are solely responsible for 67% of issues. It means that designers, developers and content providers must cooperate early on, in the design phase, and really do their best to define semantics, behaviour, naming, roles and so on. Annotations in design must include decisions that developers need to implement.
If developers and designers work in “silos” it’s extremely difficult as hand-over needs to provide developers with all information, so that it’s not needed for them to decide on design questions.
And it’s also beneficial that developers report back to designers what parts of the interface needs special attention. Where there are potential problems in interactions, where animation needs to be controlled and so on.
From the perspective of an accessibility specialist it can also be difficult to predict all the problems when prototypes are focused on static user interface and we don’t see the interaction flow. Where we only got a static image for a specific screen and we need to think about overflows, rotation, interactions, semantics, animations, zoomed in problems and so on.
Designers need more knowledge on semantics, especially possibilities native to HTML and ARIA and they also need to think about how will the interface work with different user settings and different assistive technologies. For this to happen we need better knowledge transfers long before designers produce user interfaces, early in the educational process. And I can even wish that our education would really benefit from teaching the core basics of accessibility as early as possible. Maybe even in primary school – teaching good contrasts for example – would benefit everybody.