Teaming up for Accessibility: How an In-House Taskforce Keeps us Current
Originally given as a presentation at IDEA11y | Inclusion, Diversity, Equity & Accessibility, May 25–26, 2022.
Virtually everyone will experience some form of disability at some point in their life. At Context Creative, accessible design is not just a matter of legal compliance — it’s everyone’s business. It’s about quality of life, enabling a higher quality of service and engagement and contributing to a more inclusive world.
Let’s be clear — as a creative studio, we’re not accessibility specialists. We’re not, for example, a company focused on remediating PDFs or auditing other companies for compliance. And those are not spaces in which we aspire to work in. But we do strive to continually learn, share and implement best practices to make things more accessible, and believe that:
- Accessibility affects everyone
- Every project, every interaction, involves accessibility
- You’re never done learning about accessibility
- Accessibility is not a “one size fits all” checklist
Our Accessibility Taskforce is a multidisciplinary team that we created to stay on top of issues and trends and document best practices. Earlier this year, Mary Huang and Christine Hogenkamp, who lead the Taskforce, shared their story at IDEA11y, a leading accessibility conference hosted by the University of Guelph’s OpenEd Open Learning and Educational Support department.
The presentation shares experiences, insights, learnings and challenges and summarizes:
- How we addressed accessibility prior to creating the Taskforce.
- Why we saw the need for something like this Taskforce.
- How we got internal buy-in.
- How we evolved the Taskforce as our team changed and doubled in size.
- How the Taskforce operates today.
Today, our accessibility is more robust, multi-faceted and better incorporated throughout our processes. It’s our hope that this talk will help other organizations, even those with limited resources, establish their own sustainable approaches to accessibility.
Download the presentation slides
MH: So, hello from the Context Creative Accessibility Taskforce. We are your presenters today, my name is Mary Huang and I’m an account supervisor at Context Creative. I’m also one of the founders of our Taskforce, and on the Taskforce I provide an account team and client perspective. And with me today is my amazing colleague Steen who will introduce herself.
CH: Thank you Mary, my name is Christine Hogenkamp (I also go by Steen) I am a front-end developer at Context and the accessibility Taskforce lead, I provide a developer’s perspective.
MH: Thank you Steen. So let’s start with a brief introduction to Context Creative to give you some context on Context and help you understand more about our perspective. Context Creative is a medium-sized creative studio, what this means is that every single day we juggle internal and external accessibility-related situations, so this includes things like staff training and support, client education and, of course because we are a creative studio, crafting accessible communication experiences.
And some quick facts about us: we are an award-winning Toronto-based creative agency established in 2001. We are currently two active principals and 32 full time staff. We offer full service from strategy to execution: we do print and digital campaigns, brand and content strategy, stakeholder engagement and user research, UX/UI, development, animation and more.
We specialize in purposeful design and communications, particularly for clients in regulated sectors. For example: energy and environment, health care, finance, and we also work with cultural organizations and not-for-profits.
We’ve had projects recognized by organizations such as the Association of Registered Graphic Designers (RGD) as accessibility best practice case studies: this includes government reports, and educational microsites. And we regularly consult for many of our clients on accessibility best practices.
So what is this Accessibility Taskforce we keep talking about? This Taskforce is… us! We’re a multidisciplinary team: the core group is about 8–10 volunteer staff, but the number of active participants at any time varies depending on staff availability and what’s happening in the studio.
This team represents all the major disciplines covered by Context Creative, this includes:
- Account/project management and client perspective
- Print and digital design and development, motion graphics and animation
- Digital marketing
- Content and copywriting
- Production and quality assurance, and also general operations
The Taskforce focuses on continuous learning, sharing and implementation of best practices to help make things more accessible. As a team, we collaboratively distribute responsibilities and create shared accountability.
When I started at Context Creative about 10 years ago, this Taskforce didn’t exist. This presentation is a summary of our experiences and insights over the past 5+ years, it’s essentially an overview of how Context Creative:
- Addressed accessibility considerations prior to the Taskforce.
- Why we saw the need for something like this Taskforce, and how we pitched the idea to the company owners/principals.
- How we evolved the Taskforce as staff changed, as the studio doubled in size.
- And how we operate the Taskforce today.
So our hope is by sharing our story — our trials and errors and learnings and successes — that we can help other organizations who may also have limited resources establish their own sustainable approaches to accessibility.
I want to share a little bit about our culture, because the development of the Taskforce embodies all of these things. For any organization it’s really important to reflect on what your culture is like, to figure out what might work best for you.
A few years back as we were growing, we took some time to pause and reflect on what makes us tick — what we care about, what our philosophy is — so that we could continue keeping these things in mind as we grew. And we determined these were our core values:
- To deliver excellence
- To be creative and agile
- To uplift and respect others
- To be true partners
- And to never stop learning
There’s more detail to each value, but that’s it in a nutshell, and you can learn more about them on our website. And you’ll see a lot of these themes come through as we talk about what we went through.
Our attitude to accessibility is the foundation of a lot of our approach. As a creative studio, we’re not accessibility specialists, and what this means is we’re not, for example, a company focused on remediating PDFs or auditing other companies for compliance. And those are not spaces in which we aspire to work in. But we still have an important role to play.
And I think in many ways I’m probably speaking to many of the converted already: you’re probably here, attending this presentation, because you believe accessibility is everyone’s business, and you want to contribute to a more positive and more inclusive world.
The principles that we focus on, which many of you likely share, are that:
- Accessibility affects everyone
- Every project, every interaction, involves accessibility
- You’re never done learning about accessibility
- And what this means is that, in practice, we recognize accessibility is not a “one size fits all” checklist
As our values on the previous slide indicate, our team culture is very inquisitive: we want to really dig in deep, we don’t want to just follow instructions without understanding why.
So we recognize that technology is a tool that can be used to help support accessibility, but it’s not the same as accessibility — and technology is always changing, so we’re always learning. The better we understand accessibility principles and best practices, the more effective we can be in problem-solving and helping to create effective solutions from the ground up.
For example, if there’s a communication piece being developed, sometimes people may default to thinking about resolving accessibility needs as “OK well, if we’re making a communications piece, we’ll make an accessible PDF of the piece.” But if we dug a little bit deeper and thought about it and considered the situation, maybe an accessible PDF isn’t the best solution for the project and for the project’s audiences.
Practically speaking, understanding the principles and sharing them, and helping other people to understand them, helps us to do our job better, and helps us provide more value to our clients as well.
Let’s turn the clock back — what was accessibility like at Context before the Taskforce? How did we deal with questions as they came up?
What did Context Creative look like back then? About five plus years ago, we were a small to medium-sized studio, approximately 14 to 20 staff over that period of time. On the screen is a diagram of an approximation of what our team composition was like back then: So this organization chart depicts 2–3 company principals, an admin assistant, bookkeeper, three project managers, and the studio itself was 1 writer and a mix of 1–2 developers, 3–4 designers, which some overlap of skill sets.
Overall as a studio we had a decent grasp of accessibility. We were not newbies: we had already worked with RGD and Government of Ontario, various ministries and healthcare clients to develop materials and resources: print, digital, even conferences.
There were gaps in our approach to accessibility. I’ll summarize these fairly high level, and depending on your situation and organization, some of them might sound familiar:
- Information on practical application was very siloed: it was on project-to-project basis, and the learnings were with individual staff on those projects.
- We didn’t have a specific policy on staying on top of accessibility and consistently applying that across all projects. So what was happening was people were gaining knowledge by having to solve problems as they came up, but these solutions would be in people’s heads. So if someone got sick or went on vacation, or even if someone wasn’t working on a project or issue and simply wasn’t aware of it, we didn’t have easy access to that info anymore.
- Some staff became unofficial go-to’s, helping to answer questions on other projects and initiatives, and it became hard for them to do their own job and also deal with these questions for other projects they weren’t technically working on. And of course training someone else, as we know, takes time, and if that person got busy or went on vacation, we were in the same situation again.
- We didn’t always actually always know how we solved a problem: for example, when troubleshooting accessible PDFs, we’d be doing lots of searching and poking at things and running the checkers again. This lack of predictability was challenging not only for managing our own time but being able to provide value to our clients.
- Beyond this inability to consistently remember, to build on our knowledge effectively, we weren’t actively looking out for new information or tools: so we were being reactive instead of proactive
This was an ongoing challenge, and we knew this wasn’t sustainable. At the same time, because of our studio size, it didn’t make sense for us to have one person dedicated to nothing but accessibility. So I took some time to discuss with the staff who were most often involved in accessible work and research, these were the people who had become those unofficial go-tos, and we came up with an idea.
We envisioned a Taskforce and we pitched it. This sounds fancy, but essentially I wrote a long email to our principals outlining some of the challenges I summarized on the previous slides, and proposed an idea for a solution.
Because of our company culture, I was pretty sure we had a compelling case, and there would be interest and support. Depending on your organization, you might want a little bit more detail in your proposals, and focusing on different aspects, maybe a more formal cost-benefit analysis, looking at time and resourcing, legal considerations, that sort of thing.
At the same time, I also wanted to make sure I proposed something that wouldn’t completely derail the rest of our operations. We didn’t have a huge number of staff and resources, and everyone was juggling a lot. So there was a lot of recognition in this pitch that this would be a starting point to finding a better way, with a commitment to try: to try new things, to be open to change over time.
We started with what seemed obvious: we didn’t feel an individual-based approach was working, didn’t seem sustainable, so let’s have a team-based approach. What could this look like?
We envisioned a Taskforce with a mandate: a team of people who are committed and supported to stay on top of things in this area on a regular basis. The idea is that this would be a more balanced solution that helps to spread the workload as well.
The team could figure out accessibility issues together, do research and troubleshooting together, and then document and disseminate that to the rest of the studio and help make sure there’s clear and consistent understanding and implementation, and hopefully minimize things falling through the cracks. Everybody in the studio, whether or not they were formally on the Taskforce and actively involved in this research, would be expected to understand the findings and recommendations from the Taskforce.
Our starting team was 2 project managers, 2 developers, and 2 print designers, and the theme of twos is for continuity of knowledge if anyone is away, and also helping to share the workload and the expertise of certain areas. We saw this as covering all the specialty areas that we were really focused on at the time: print, digital, speaking to and educating clients, scoping projects. The team was formed from studio volunteers who expressed interest.
Our first step was to collect and review all the documentation: information and resources that we had at the time that we were aware of; things from emails, from client policies, things we had on our internal wiki, and so on, and then figure out how to organize it. We would go through them, identify gaps in our own knowledge and process, and start to distribute the work to help fill in those gaps.
On an ongoing basis, at least 2 people on the team were involved in any accessibility questions that we ran into. The Taskforce would meet regularly for updates (once or twice a month) to share things we’ve encountered, share things we’ve learned and help make sure it gets documented and basically hold ourselves accountable.
When there’s a big enough accumulation of new knowledge, the idea was we could do a larger studio lunch and learn, and have information and research, with nice handouts, to be able to make clear recommendations on our processes.
One thing you may immediately notice is that on these slides, there’s nothing really wild or mind-blowing. And to be honest, a lot of these things were already being done on an ad hoc basis, we just didn’t properly document or share them: we didn’t have an established process, we didn’t have established expectations of what was going to happen. That meant there was no centralizing, no redundancy, no continuity in case something happened. This was a bit of formalizing of things we were already doing to some extent, and helping us connect many dots.
Of course, there is always a difference between expectation and reality. We learned as we went, and here are some things we learned about what worked and didn’t work for us.
We ran into some challenges:
- Scheduling Taskforce meetings: It was hard to find time for everyone to meet during busy periods: everything had to be done in between paid client work and other responsibilities.
- Long, unproductive sessions: So we had meetings that would turn into really long sessions where some people were talking and others just sitting around because it was a technical discussion that didn’t require their particular area of expertise.
- Team members not being kept in the loop on issues or learnings: Trying to remind people to loop in the Taskforce and not continuing to ask only the 1–2 people who had become known for troubleshooting accessibility was a challenge. But at least those people now knew they had a team behind them they could update and bring into the conversation, and they were feeling less overwhelmed.
- Trying to loop updates back into the studio in a timely fashion: sometimes there were lots of things happening and it also didn’t make sense to do a big lunch and learn, so sometimes things would slip.
- We had missing perspectives and some disciplines were not represented: for example, we had no writer on the original Taskforce, as our writing staff was much smaller.
- Overloaded co-ordinator: Client-facing senior team member (me) who helped to establish the Taskforce was getting a little buried under other work in terms of both short-term day-to-day and long-term operations initiatives. The busier we got, the more client communications I had to manage and I was having a hard time coordinating and keeping track of everything going on, especially the very technical nitty-gritty details on the Accessibility Taskforce.
So we made some changes to try to find different solutions to these challenges:
For the scheduling of the meetings, we experimented with different levels of involvement from the whole organization: instead trying to schedule meetings for everyone on the Taskforce to be available, we tried instead inviting everyone who wanted to attend, but at minimum one person from every discipline had to be present or have a representative who would take information and updates to them. The attendees would be responsible for helping to make their studio team aware of updates, for example the account management rep would update account managers, the developer rep would update developers, and so on.
For the long, unproductive sessions, we looked at refocusing those monthly meetings to focus more on high-level run-through of to-dos. For example, we have a list of tasks from the last meeting, and we go through them and look at: is the task active or are you done, do you need any help?
And the further discussion for any one of these tasks would be a separate meeting to be set up with the people involved instead of taking up the rest of the time at these larger meetings. Sometimes we still do get into the weeds during our meetings but we’re much better than before, we’re getting more and more efficient and everyone is keeping an eye on these things as well.
For team members not being kept in the loop, we started using more project management and collaboration tools to try to manage and share progress and information on an ongoing basis. We tried a lot of different things and this actually helped us a lot too when the pandemic started a few years later and we were looking at more remote work.
We discovered ways to address those missing perspectives; as we grew, we added more specialist disciplines to the team: writing, animation, digital marketing and so on.
And for the overloaded coordinator, a non-client facing team member volunteered to take on the lead coordinating role and that was Steen! And this is a perfect place for me to hand it over to Steen to take us through where we are today, so take it away Steen.
CH: Thank you, Mary. So… the Context Taskforce: where we are today. We’ve grown and expanded! We are now a staff of 32 people, and our Taskforce includes representatives from the six largest disciplines, plus a flexible number of participants: this includes designers, animators, developers, account managers, copywriters, and the digital marketing team. And on this slide is a chart of the more complex system we use to organize each sector, as we have so many more junior and senior people to keep organized.
As well, we often have regular office staff volunteer to attend the meetings of their own interest. Proactive participation is always encouraged!
And our clients and projects have grown along with us: as Mary mentioned, we work with many clients including government and public sector organizations.
We provide consulting on best practices for various types of media, using info from our existing knowledge base, and we also consult with industry leaders and actively monitor what is happening in accessibility spaces around the world.
We’ve been able to apply our insights to:
- PDFs including fillable forms, where we provide relevant insights for the design of various documents, as well as improved technical specs.
- In-house templates as part of our workflow.
- Website development and accessibility audits: we use both automated checkers and manual audits. We also build websites using our own developer library of accessible components.
- Accessible videos and animations, making sure they include special considerations such as closed captions.
- And other marketing applications, where we advise on best practices for social media and client brand palettes.
And when appropriate, we partner with specialists to ensure we follow best practices and help make expert knowledge accessible to our clients.
And as Mary mentioned, a new lead has arisen in the Taskforce — it is me! As the workload of original coordinator (Mary) grew, a new Taskforce coordinator volunteered on the basis of:
- Less client-facing workload and more flexibility of “free time” — I’m a developer who does relatively few client meetings or other client-facing work, and my work tends to be shorter development projects (days vs weeks or months) which gives me more flexibility to coordinate tasks such as reviewing task updates, contributing to various discussions and also answering questions on a day-to-day basis.
- I also have an active interest in accessibility and improving project workflow, as well as creating clear how-to docs for better project efficiency and controlling those nitty gritty technical details.
Also, we expanded the duties of the Taskforce lead to include:
- A coordinator for requests for help from Taskforce, from anyone at Context
- Keeping tabs on various accessibility best practices, such as: are we up to date on our how-to docs, and have we learned anything new to improve the end results?
- And also, actively encouraging and advocating for accessibility mindfulness in our day-to-day work and office interactions.
The Taskforce today acts as an accessibility hub: it’s a centralized knowledge base made up of volunteers and written resources.
The benefits of this hub include:
- Everyone is empowered to act as an “accessibility officer” through training and access to documentation.
- So the mental load of “knowing accessibility” is more evenly distributed and more readily accessible.
Access to Taskforce meetings for all staff also creates opportunities to improve understanding. Staff can attend meetings directly or pass on their requests through one of our reps to ask for help. Complex problems or client inquiries can be reviewed and researched by multiple people. Everyone feels supported in having a team to help double-check assumptions or help research answers. That gives us the ability to address client questions with the help of our Taskforce, who will assess and provide necessary information or explanations, and be confident that we will have a multi-faceted, well-thought-out, well-researched response.
We also have the ability to track long-term progress for troubleshooting technical issues or updating existing documentation. This includes more complex projects that require research and testing, or improving on existing methodologies as new information is discovered.
As an example, this slide includes a screenshot of a post from our Basecamp Taskforce message board, where I had created a summary of our current knowledge for creating accessible PDFs and the status of each type of document element, as quick reference to which elements were formatted correctly and which elements needed a bit more research or testing to further refine the results.
In the past, our Taskforce started out using email plus an internal wiki (that Mary had mentioned) that acted as an intranet (and also Google docs) as the tools that helped us document our accessibility efforts: they were low cost and easy to collaborate with.
Today, the tools we use have expanded and they include: for organizing our tasks, training and documentation, there is Google Docs and Airtable, which we use for tracking complex data and resources and Basecamp, to coordinate the Taskforce team and ongoing to-do tasks. Basecamp also serves as a repository for relevant helpful links organized by topic (ie., for designers, for developers, for copywriters, etc) or for tracking conversations on more broad or complex topics, to give everyone an opportunity to contribute.
We also have the Infohub that started out as an internal wiki using free software and evolved to become a customized Wordpress site as a central hub for finding various documentation links. This internal hub also contains info about our accessibility best practices, for training and reference purposes. Wordpress is a CMS (which is a Content Management System), and the benefits of using a CMS is that it has a more user-friendly interface that allows more staff to help keep the site up-to-date, and no code is required for updating.
We use Assistive Technology for testing purposes: these are a modest selection of assistive tech that are within our budget, which allows us to improve our testing of various digital media. And the effort to better incorporate these technologies is ongoing and evolving over time.
Screen readers, like NVDA and VoiceOver. Audit software and online resources: PAC3, Lighthouse, Achecker, WebAIM Color Contrast Checker, Coblis Colour Blindness Checker, WebFX Readability Test Tool
Start with low-cost or free tools and when paid tools are necessary, explore what options are within your budget.
And lastly, we have news resources: I signed up for various accessibility newsletters to stay current in accessibility news and technology, to share with others at Context. Some of the newsletters I signed up for include:
- WebAIM Web Accessibility E-mail Discussion List (webaim.org/discussion)
- A11y Weekly (a11yweekly.com)
- AODA Toolbox Newsletter (aoda.ca/newsletter)
I like to share articles that have perspectives of people with disabilities, opinions of experts in the accessibility community, and also legal updates especially those aimed at Ontario and Canada.
So looking back at how we started, as Mary had mentioned:
- Accessibility expertise was limited to a few individuals on a per-case basis, with some documentation for repeat projects like the accessible PDFs.
- New learnings were not always captured after the project had ended, and it was hard to find past info without having to dig through email chains.
- Basic audits were done using only automated checkers, some errors were not discovered as a result of this.
- When the Taskforce was created, leadership was limited to one person who became overwhelmed by other commitments.
- Overall, accessibility considerations and understandings were more limited.
If you compare us to how we are now:
- Accessibility is part of our onboarding for all new hires & all staff are given training. Accessibility expertise is something anyone can have and should have, and there are ongoing efforts to improve our best practices.
- Accessibility info and tutorials are clearly documented for reference by anyone for any project: how-to docs and other relevant information such as resource links and tutorials elsewhere on the Internet are organized through our Infohub and through the Taskforce group on Basecamp.
- Our audit process starts with automated checkers but now uses other tools including assistive tech, with improved error-fixing. Our accessible audit process has been refined: we took our existing audit process and found ways to add manual audits to check for things such as correct logical reading order, correct tag usage, and other elements. We often use the screen reader NVDA in our testing and we are exploring other assistive tech options.
- Taskforce now led by a person with fewer client-facing responsibilities and the Taskforce reps help share the load.
Overall, our accessibility is more robust, multi-faceted and better incorporated throughout our processes. So our advice to other organizations is basically: start small, adjust as needed.
“Don’t let the perfect become the enemy of the good” — this is a favourite saying of mine.
Start in a way that fits your organization, build from there, learn and improve, and adjust existing resources as needed. Adding accessibility to your organization is a process, and it can’t just be purchased as a ready-made, use-straight-out-the-box product.
It starts with recognizing your existing resources within your organization: use the tools available to you, but emphasize tools that allow for collaboration and easy use/access/editing for everyone involved.
Start your own accessibility hub: a landing page or portal for links to documents, websites, and other resources. And start documenting important processes: any technical processes or workflow that are specific to accessibility or a specific product or service, and make this documentation available to everyone.
Look for experts from the accessibility community, to help get a better understanding of the big picture of accessibility in Ontario, in the US, internationally, wherever your organization does business. Be aware of the “politics of the day” and how they affect your organization.
Be aware that guidelines and checklists from accessibility experts are a good starting point for establishing accessibility best practices, but you do also need to educate everyone to a level that allows them to understand what these standards are trying to achieve.
Explore options for adding accessibility tools, depending on the types of projects your organization works on or services they provide, such as:
- Screen readers or other assistive technologies
- Software for creating accessible PDFs
- And testing software for accessible websites
Find motivated coworkers to lead and inspire: not just lead the efforts for better workplace project practices but also to look for ways to inspire interest in accessibility for all departments or types of team member. Accessibility is a part of everyday life and that includes the workplace, and for every type of job there is an opportunity to assess accessibility and make improvements.
Following on that idea, create a culture of support for questions and learning, for team members to actively think about accessibility and give opportunities for answering questions and providing clarification.
Also consider how you will manage client or stakeholder expectations: review client-facing workflow to adjust timelines for new accessible aspects to projects, and ensure Account Managers are empowered by documentation to answer client questions and provide supporting information from official sources as needed.
Lastly… you can do it! We believe in you! Thank you very much for attending our presentation.