You may have heard the anecdote of the frog being boiled alive. Apart from it sounding like a torturous way for a poor frog to die, the metaphor, however you take it, can also be used in business to reinforce that change needs to be gradual to be accepted.
A strange analogy for accessibility, I know. But this analogy is exactly the approach organisations should consider looking at to improve accessibility and achieve behavioural change in their own teams. Rather than expecting digital teams to instantly pick up all they need to know about accessibility or undertake the odd workshop here and there, the best approach is to provide the information and tools required around their everyday work.
The key is to get started!
It may not always be the ideal approach, but for some busy teams it’s near impossible to send them all off to a one-day workshop anyway. However, you can get started. A really practical approach is to begin by ‘baking in’ accessibility into the next web development project. Depending on the development approach, whether it is iterative and agile or a more traditional specified approach, or a hybrid, accessibility can be embedded in and punctuate the project timeline when key aspects are being delivered. For example, when discovery and planning is conducted, the project manager can brief the team on the basics for accessibility and allow time for accessibility checks to be completed. Any user stories can include people with disabilities. An accessibility check once wireframes have been developed can advise designers and UXers on issues relating to colour contrast, visible focus on different focus states, heading structure and hierarchy, focus order, images of text, meaningful links and a whole lot more depending on the layout and structure for content.
Testing the accessibility of front-end templates will identify coding-related issues such as labels on buttons and fields, focus order and meaningful sequence, and ensure that there is no use of colour alone as a distinguishing feature. Developers may also require ad-hoc help as they begin development and come across inaccessible widgets or web parts such as carousels, news sliders, social sharing or calling database driven content.
Finally, by conducting accessibility testing at the end of the process you should find that the website or app is largely accessible if the team has been able to follow this process. Your digital team will also be a little more educated about how to create an accessible digital presence.
If you consider embedding accessibility in at every stage there is a greater chance of having the findings educated back into the team by getting them fixed as they work rather than waiting until the whole website or application has been developed.
Practice makes perfect!
Just like cooking frogs perfectly, accessibility takes practice. The best way to effect positive behavioural change is to ensure accessibility is included in the ‘definition of done’. This means that each person in the team is aware of their role and what they need to contribute to an accessible digital frog (just making sure you’re paying attention).