A follow-up to my talk at A11yTO
I cannot pinpoint the source of this misconception, it could have been a vendor, or long-lost blog post, or one of the many webinars I attended in my early days as a program lead. Regardless of the source, I operated under the wild misconception that all I needed to do was train my teams to do accessibility. Developers, QAs, designers, all they needed was training!
This model was encouraged by senior leadership, and it's easy to see why. Even though accessibility training was expensive (I probably spent about $50k CAD in the first year, and around $20k per year since), it was still far cheaper than bringing in expertise in the form of accessibility professionals.
The idea behind training was that while we still needed a subject matter expert (me), my role would be an advisor and program manager, teams would only need me once they'd exhausted their research or newly-gained knowledge.
This model does not work. Especially for an organization with multiple products, multiple platforms, and multiple development teams.
Two years into the program, I started to see this misconception fall apart, and since then, I've been trying to pinpoint why this idea is common, why it doesn't work, and how we can solve it.
There is a lot that contributes to this problem, but I've tried to narrow it to three problems:
Accessibility is not yet taken seriously as a technical specialization
Accessibility as a compliance exercise instead of an ongoing practice
Web developers don't know HTML anymore
Accessibility as a technical specialization
Prior to my transition to accessibility, I worked in the QA field in QA Strategy. My job was to look at projects during the discovery phase and determine what kind of testing resources or methodologies we'd need to use to succeed. One of the many projects I worked on was integrating security practices in our development process (for those in the field, this is often called DevSecOps).
From the start of the project, we knew a few things:
We'd need professional help from a SME (subject matter expert)
We'd need tooling support
We'd need a dedicated development team
Getting support for everything in the list was straightforward, and the project went smoothly. Budget and resourcing, which at the time weren't my responsibility, seemed to come readily, or with relatively little convincing on the part of my managers. Today we still have a dedicated security team.
I attribute most of the ease of this process to the fact that in software development, security is a recognized technical speciality. That while everyone who writes software should have a concept of security and best practices, it's a complex field, and if you want to do it well you need people with expertise. There are many recognized technical specialities in software development, and as we've seen tech stacks grow, people have been able to carve out niches for themselves as specialists in any number of languages, frameworks, or specialities.
Yet we don't see this for accessibility, at least not at scale. Some people within the industry have carved out those niches for themselves as accessibility designers, engineers, and other roles, but they're a minority. The best indicator of this problem is seeing job postings for "accessibility specialists" that list a skill set that seems to defy time and space. Most organizations expect accessibility specialists to be able to competently perform development, QA, design, education, documentation, and project management tasks at the same time as being a SME on topics relating to legal standards, web standards, best practices for mobile apps development, etc etc etc.
Core to the assumption that accessibility specialists can and should be able to do everything relating to accessibility is the undervaluing of accessibility knowledge and skills. And an extension to that line of thinking is that accessibility, since it is something that has such limited complexity (how can it be complex if one person can do all that?), is something that can be trained for. All of the accessibility knowledge a developer needs can be passed over in a three day training session.
Accessibility as a compliance exercise instead of an ongoing practice
If accessibility is treated as a box-checking exercise on a routine cycle of auditing or only when something goes wrong, the work is further devalued.
Just like with the security example, everyone should be responsible for accessibility. Not just for compliance reasons, but as a practice. The only way to make that successful is to have proper supports in place for those teams to succeed. Those supports come in the form of accessibility specialists who specialize in the technologies/products you are working on.
It is important for me to emphasize that when I saw training won't solve your problems, I don't mean you should never do it. It can't be the sole means of supporting your teams in building accessibility practices.
Training is for learning the basic skills and principles to do accessibility, and the essentials of tools and tricks for testing. Once the training is over, teams will need the support of specialists to answer the inevitable questions and challenges that arise from working day to day.
If you're lucky, some of the developers, testers, and designers you train will discover accessibility is something they are really passionate about. Maybe so passionate it becomes their speciality! What is more realistic is that they'll see it as another requirement, maybe one that they don't mind, or an annoyance, but they'll get it done if they have the support they need.
Web developers don't know HTML anymore
Before someone swoops in with "not all web developers", I don't mean all web developers, obviously. However, it is a trend I've seen in my workplace and have heard the same from others. Web development today is more and more abstracted away from HTML, most developers working in frameworks like .NET, React, Angular and so on don't need to know HTML to produce websites that look and work the way they expect them to.
It's probably more accurate to say they don't need to know the intricate details of HTML to do their work. Most of my colleagues know that they should use <button> and <a>, but forget that we don't need to apply `tabindex` to them to make them focusable.
This is the kind of technical specialization I'm talking about though, since we all know people in accessibility doing brilliant things with proper HTML and CSS. We also know how accessible websites perform compared to their inaccessible counterparts in metrics like performance (which is also tied to sustainability).
I'm a recovering teen website builder, I never have and never will consider myself a developer. Though some days I reconsider my position after carefully explaining the accessible name calculation algorithm to my coworker with a computer science degree and no knowledge of why putting <label> inside <button> is not actually how we name buttons.
Training will not save you
It would take a whole other blog post to delve into the possible reasons why accessibility specialization and skills are as undervalued as they are in our industry. Ableism, sexism, capitalism... it goes on and on. Those are big problems to solve, and if you're reading this, you're probably looking for a much quicker solution than trying to overturn an entire economic system.
The quicker solution is hiring specialists who are specialists in the true sense of the word, or allowing people to specialize once they've gotten their foot in the door of the accessibility field. Pair your web teams with web specialists, your apps teams with apps specialists, your designers with an accessibility designer! Give your teams the tools they need to succeed, and support them with training you can commit to supporting long-term.
If hiring is not on the horizon, a reality I know many of us face, there's other options. Depending on the bandwidth of you or your team, you could engage with your developers in code review, before things are merged into environments. Instituting testing requirements like running axe-core or WAVE in local is another option, and there are a variety of accessibility linters out there for frameworks like react. If you have any accessibility champions or particularly literate developers, you can leverage their skills to support you and their colleagues.
In addition to training you can run continuing education sessions with your teams. It's particularly effective when it can be done in context, showing their own code and how it renders on their own projects. It does not need to be an exercise in public shame, but an opportunity for people to learn how their work impacts the accessibility goals you all share. Keeping the sessions bite size and related to their work also reduces the load on you and the teams.
Whilst training is not the be-all-end-all solution many of us are promised, it's a step towards a solution. I still use it, I still recommend it, it just needs to be part of a larger and more concerted program and effort.