Scaling inclusive environments begins with community building. We created an Accessibility Handbook to help you get started
Ten! Ten years, that’s how long I’ve worked in accessibility within the public service. I’ve watched the community grow and change as new faces have come and gone. Many people involved in accessibility in the public service when I first started out are still spearheading the charge today. We are a small, but mighty community, crossing departments and sectors to help improve access to services for people.
I often get asked how I started working in accessibility. For me, that answer comes from my lived experience. I have a disability, and so do other members of my family. My father became disabled by accident when he was 38. My sister was born with a disability — she has a chromosome abnormality. And while I knew about disabilities, I never thought of it as a career option for me.
One day while I was at work in 2007, I met a colleague who was blind. I asked him what kind of work he did, and he responded by saying that he worked on testing for accessibility. I was intrigued, and asked how he came to do that as his job. I was invited to meet a small, but passionate team of accessibility experts. During a coffee chat, I asked: “How can I come work doing what you’re doing?”
Just a few weeks later, I moved teams and the rest is history.
Over the last decade while working as an accessibility practitioner, I have noticed that many folks don’t know what they need to do to make something accessible — to build accessibility in, from the beginning. I noticed more and more that people would be overwhelmed if you simply sent them a list of links and resources like the Web Content Accessibility Guidelines (WCAG) standards. People wanted to know what they could do in their own role, and often, they didn’t have time to read hundreds of pages of documentation, much of which they didn’t understand.
When I first heard of CDS, I wanted to know more about how they approached accessibility. One day there was a Twitter post asking for feedback on a new tool that was in alpha. I took a quick look.
- I went through their product with two tools for automated testing.
- I passed through it using keyboard navigation to try and complete tasks.
- I did a quick colour check.
- I drafted a small note and posted it to their GitHub repo.
I didn’t yet work for CDS, but they were publicly requesting feedback and I was part of the accessibility community in government and wanted to help. They were responsive, interested and took action immediately to start making changes. Six months later, I was hired as their accessibility and inclusive services lead.
The more projects I worked on at CDS, the more I became aware of the need to engage multidisciplinary teams on accessibility. Over time, people come forward as accessibility champions. We did a lot of research and some trial-by-fire to see what resonated with developers, designers, product managers and the rest of the delivery team. We started small. I organized a panel of service design barriers. We listened to public servants with disabilities talk about the barriers they faced using government services.
We hosted accessibility days and started documenting the changes we were making. We started running accessibility clinics, then paired accessibility reviews, and as if by magic, team members started taking action on accessibility on their own. We were building GitHub actions for accessibility in the continuous integration processes, building in accessibility from the start of iterative products, and testing them with users.
Developers were talking to developers in other organizations about the importance of accessibility testing and how they could automate it. More importantly, they were talking about the need to do manual testing too. Designers were sharing articles, tools and tips on how to design accessibly. Plain language has also become a staple in our vocabulary. The impact of having someone in an organization talking about accessibility and inclusion on a daily basis paid off in unexpected ways. I wrote a personal blog post and shared it in a slack message on how comms teams can improve accessibility. Weeks later, I saw our own comms team was implementing accessibility in new ways.
We have developed an accessibility community by using empathy, being engaged and prioritizing it.
Four months ago I started having open office hours for accessibility across sectors. In that time I’ve had over 50 requests for support. I have shared information on accessibility, inclusive design, ethics, design thinking, data & research.
Biggest questions?
- How do I get my leadership to care?
- Who should pay when something needs to be made accessible?
- What is the law?
- How do I learn to test for accessibility and build skills like you’ve done?
What’s next? The goal is to help scale inclusion across the government.
We started our journey to create the Accessibility Handbook to respond to this need. The handbook is an iterative product that we will be updating and adding to regularly.
To start, you will find information on:
- Automated accessibility testing
- Manual testing
- Usability testing
- Tools you can test with
- Tips on creating accessible documents
- How to conduct a paired accessibility review
Sharing resources, working collaboratively and building community across government will help us build a more inclusive public service.
Check out our Accessibility Handbook.
We can give a voice to people by telling their stories and sharing their truths in order to help teams design more inclusively. Creating a culture of accessibility and inclusion is about making sure everyone who works on, delivers or uses your services or products can access them.
The Government of Canada is a leader in creating equitable experiences for everyone. Sharing resources, working collaboratively and building community across government will help us build a more inclusive public service. The Office of the Chief Information Officer is marking IDIP2019 by publishing new guidelines for the public service which encourages them to leverage the Harmonised European Standard EN 301 549 when procuring or developing information communication technology. Together we can make more inclusive services for everyone.