Sometimes accessibility for web and mobile seems to be very code-oriented. Use semantic HTML, use correct CSS to hide, extend with ARIA, use JavaScript for interaction and so on. But to make digital products really accessible we must think of accessibility long before developers start with their work.
Research the end user – what will typical audience be
We should know our end users to be able to know how to serve them best. One can go with personas or just think of typical user base. But personally I do not have the best experience with it. We can use personas in typically business-oriented manner or from the peoples with disabilities aspect. Sometimes combined. Then we can also combine different disabilities per single person. So we are quickly drifting away from simple grouping toward advanced matrices. It may get too complicated to handle.
I can argue that understanding Web Content Accessibility Guidelines (WCAG) at design level helps enough. We can get into personas if we have enough budget and time but then we also must take care that others are not left behind. So I think it is best to understand the spectrum of disabilities and WCAG and then apply this knowledge. WCAG does cover multiple needs and is also evolving based on real-life experiences, so it is a key to implement accessibility.
Sometimes it is also difficult to know about typical audience. Especially when targeting new markets or with very innovative products. I am not saying that we should drop personas, but I think that they are maybe not needed for all projects and products.
Content management systems (CMS) should also be accessible but very commonly neglected. I can only guess that it has to do with legislation, at least in the European Union. But please do think about your own employees as well. Often we are locked-in into existing CMS and if they are not accessible then we should discuss how can they be accessible with our provider.
Design and wire-frames need to think about accessibility to make it happen
Design, both user interface and user experience has a lot to say about accessibility and can on the end of the day make it or break it if you want. A huge part of WCAG success criteria is targeted on user interface design and it is absolutely important that designers think inside the WCAG frames when making their masterpieces.
Accessibility does present some sane limitations and rules that needs to be understood and respected for it to work for broad spectrum of users.
When we think of applied WCAG for designers we can notice that they have to define or at least know about the following:
- page structure, regions and headings,
- navigation patterns,
- all colors used,
- contrasts on text and non-text elements,
- readability and typography,
- responsive design and reflow,
- screen-orientation differences,
- best practices for form design,
- gestures and other special interactions,
- micro and macro animations,
- feedback and status messages,
- the big picture.
When developers get their hands on design briefs, they should also be briefed on special accessibility features that are mostly not obvious visually. So it is again necessary for the designer to define accessibility on the brief level and explain it to stakeholders, developers and testers as soon as possible.
User testing wire-frames, prototypes and minimum viable products
When designers reach out of common design and accessibility patterns we should think and discuss accessibility even more deeply. When possible we should test early, with people with disabilities. Sometimes it is not possible, but ideally we should test as soon as when in wire-frame phase. If this kind of tests don’t cover all WCAG success criteria then we can choose to make a simple prototype that already implements every accessibility need and test for remaining afterwards. It can be impossible to test wire-frames with a screen-reader, but prototype, proof of concept or even minimum viable product can be easily tested.
Shifting left in the product lifetime
Shifting left means start early, at least in the western culture, when we start reading and writing from the left to the right. We should really shift accessibility left, on the whole picture – from A to Z. That also goes for design and initial product setup, not just developing!
