Having discovered a while back that the things I’d built weren’t accessible, I’ve been learning how to make stuff more inclusive ever since. I’ve also been trying to raise awareness of these issues among my colleagues.

It seems like there’s been a recent surge in the number of articles and presentations published online about accessibility and the web. It’s probably cognitive bias - the kind where you start noticing more of something only because you recently learned about it. Either way, I’ve been helped a great deal by these resources, and I shared them with my colleagues, knowing that considered advice from seasoned professionals would make the case for inclusive design far better than I could.

When it comes to enabling more people to use our website, my colleagues all agree that it’s the right thing to do. However, when it comes to putting these principles into practice, and prioritising them within our work, there tends to be resistance. Not from the people responsible for implementation; rather, from the people who decide what should be implemented.

I’ve been trying to understand the reasons for that resistance, and figure out what lessons I can learn that might help get through these sorts of barriers in the future.

Time

Looking back, I suspect a perceived lack of time is the main reason for deprioritising inclusivity.

I should point out that I think it’s the perception of a lack of time: while time is relative, and in reality there’s no deadline except death, there are motivating factors, and the way we think about them influences our choices. I’m lucky enough never to have been in a job where failing to ship a feature on time meant instant dismissal; but regardless of the job, if you attract enough stink-eye from colleagues and managers, and are seen as someone who might drop the ball, chances are good that you’ll be passed over when any positive opportunities arise, which is a problem when you want to get ahead, especially in a competitive environment.

So you’d better come in early, and stay late, and work evenings and weekends, and worry constantly about failure, because time is money and lives are on the line!

No. Don’t do that.

Stop me if you think you’ve heard this one before

Thinking about the origin of the word project, that’s typically how it starts: a senior manager will ask how far into the future a desired objective could be met. Put on the spot, a middle manager will pick a date out of the air, with the caveat that it’s an estimate based on current workload, business as usual, holidays, etc. In other words, it could be subject to unforeseeable change.

However, the estimate might be mentioned in a meeting of the Senior Management Group. Maybe it goes into the meeting minutes. Then it becomes part of a project plan, a milestone on a critical path. Having started as a rough guess, it turns into a commitment.

Nobody wants to let the team down. Nobody wants to be seen as someone who can’t deliver on a promise, no matter how tenuously that promise was made.

The result is a climate of mild panic. Due to perceived time pressure, the team is forced to focus on the stuff we can do quickly. Anything outside of that familiar realm is seen as a potential blocker, and put on the back burner. Consequently, the resulting product only nominally fulfils the requirements.

Nevertheless, with the desired objective being met on time, ticking the box for the final milestone seems good enough. Senior management have something shiny to look at, and marketing officers have key performance indicators to measure. Meanwhile, everyone on the team breathes a sigh of relief. The project is over, and we’re on to the next thing.

In my experience we seldom return to fix problems. We might record issues that are found, but the product backlog serves mainly as a growing reminder of all the stuff we missed, and spending time fixing issues in a product that’s supposedly finished needs to be justified, since it’s at odds with getting on with new work.

While concepts like Lean and Agile and Scrum are being toyed with, and we’ve started dabbling with continuous improvement, the business hasn’t got the memo yet. The expectation is that we’re still project-based in our approach, and any other work we need to do has to fit into whatever gaps are left.

Don’t get me wrong: I’ve been quietly complicit in this scenario for many years. It’s only recently that I’ve come to realise that the way we prioritise our work has been at the expense of inclusivity, and that maybe things needn’t be this way. There are recurring themes that go into the prioritisation process, some of which bear further scrutiny.

It’s Not Really A Problem, Is It?

The last major project our team worked on was redesigning the University website to be responsive, so it would work better on a wider variety of devices. Ours was the last university in Scotland to do so.

As the senior web developer I was asked to give my thoughts on how to proceed. I’d already given the subject quite a bit of thought. Back in 2012 I attended a conference where it seemed every presentation included a slide predicting mobile web use overtaking desktop, so I started reading up on how to make websites responsive, because I knew it was only a matter of time before a senior manager would come along and say Hey, this mobile thing has really taken off. Are we doing anything about it?

Five years later, the glacial gait of the institution had shifted sufficiently to allow a project to germinate. Thankfully, most stakeholders recognised that the technical aspects of going responsive were essentially cosmetic, compared to the problems surrounding content and its governance. The resulting project put content strategy at its heart, which was encouraging to say the least. However, stakeholders also recognised that changing institutional behaviours and business processes would be an enormous challenge, one that would take time.

And the University needed a squishy website now.

Strictly speaking, the website already loaded perfectly well on non-desktop devices: the problem was the terrible user experience, with lots of pinching and zooming, and scrolling in all directions - once the page had finally finished rendering. Our team’s role in the project would therefore be a case of making the existing content work across devices.

Responsive design promised a relatively straightforward solution to the squishyness requirement, so I wasn’t too worried about the technical aspects of the upgrade. Instead, my focus shifted towards the usability of the website, which led me to inclusive design, which in turn led me to discover that our existing template code - most of which I’d built - wasn’t accessible. I won’t go into details here; suffice it to say we’d have failed most single-A WCAG conformance criteria.

As a result of that embarrassing revelation, the plan of action I subsequently drafted for the responsive project had accessibility at the top of the agenda.

I was surprised by the response I got from management. It was full of cautionary tones. The standards to which we worked were deemed sufficient for most, borne out by the lack of any complaints. Given resource limitations, I was told, it was a strategic decision not to gold-plate the service offering.

I immediately challenged these assertions, and a meeting was proposed for the following week to clarify the matter. However, the meeting never happened, and I didn’t follow up.

I resolved to go ahead and prioritise accessibility anyway. I’ve been in the job long enough to know that management don’t necessarily need (or want) to understand the particulars of what I do. Nevertheless, it felt pretty uncomfortable doing this work with the perception that I was needlessly making a big deal over something that was considered an optional extra.

So where did these management reservations come from?

View the Text-Only Version of this Website

The manager in question has a long history with the University website. Back in the day, the website consisted almost exclusively of static pages of textual content. The most complex user interaction at the time would have involved filling in a form to join a mailing list. In the context of accessibility, the standards to which we worked involved semantic markup, sensible heading hierarchy and alt attributes on <img> tags.

And there was a visually-hidden link to Betsie on every page.

Things have moved on a bit since then. We now have carousels and lightboxes, tabs and accordions, dynamic filter tables and auto-completing form fields: a plethora of peek-a-boo.

And there’s now a visually-hidden megamenu on every page.

The complexity and interactivity of our user interface has increased greatly, and it’s no longer valid to expect semantic markup and alt text alone are enough to ensure the experience is inclusive.

To be clear, I don’t think this was a case of the manager in question wilfully deprioritising accessibility for nefarious reasons. I think this was more a lack of understanding regarding the nature of the problem, and how far things had evolved, accompanied by an assumption that existing processes were enough to deal with any problems.

In retrospect, I should have followed up on the misunderstanding and worked to resolve it. I don’t particularly enjoy conflict, so it was easier to let it slide, to make excuses for not speaking up: everyone is busy, the manager probably has far more important things to deal with; if it really was that big a deal, they would get back to me for clarification; and so on.

So lesson number one is: don’t let it slide. Explain the problem, demonstrate the problem, clarify the obligation to solve the problem, and above all be confident about the solution to the problem.

The part that troubles me more is the assertion that there’s not really a problem because there’s a lack of any complaints. It doesn’t make sense, especially in the context of accessibility: how can someone complain about inaccessible content if there’s no way for them to know whether it exists or not? Does everyone complain when they hit a barrier, or is it more likely they’ll simply give up?

Empathy

If I were to suggest that any of my colleagues lacked empathy, I think they’d take it as an insult: how dare I suggest they don’t care about this stuff?! However, you can’t care about something you’re not aware of.

We don’t know what we don’t know. It’s understandable that we don’t think about certain issues until we experience them for ourselves, or are otherwise given a heads-up about it. For that reason, accessibility had slipped under the radar for our team, and I don’t think we’re unique in that regard.

We recently had a placement student with us for a week, and as part of his whirlwind tour of the department I sat him down for some role playing. He was asked to find a degree programme on our website. This would be the degree he’d be interested in applying for. He’d then have to find the same degree programme after each of the following scenarios:

When I took away the mouse, the look on the student’s face was priceless: he’d never considered that computers could be used just with the keyboard, let alone with a screen reader. We don’t know what we don’t know.

However, even though our team is now aware of the issue, from a business point of view we still need to be pragmatic. We have limited resources, and time is never on our side. We must concentrate our efforts where they will have the largest return on investment for the business. We can’t please everyone, and it would be naïve to think we could. There are going to be users so far out on the fringe that it’s unrealistic to expect us to devote the necessary time and resource to ensure they have a functional experience.

In other words, there’s not enough of them to justify the effort, so fuck ’em, right?

Numbers

Many of us are familiar with the conversation about which browsers to support: where should we draw the line? What’s the market share? What do analytics say about our traffic?

Despite the fact that our job involves supporting users rather than the technology they use, this is a conversation our team has had many times; while some might argue it’s a simple choice, there have been many occasions in the past when a scenario has upset the Apple cart.

For example, an international student recruitment officer will return from Malaysia or China or some other distant land and tell us of problems they had showing our website to potential students, and it turns out they were using Internet Explorer 6 on Windows XP. It’s an important market for student recruitment, so we’re tasked with making the website work in that browser.

We experience the exquisite delights of graceful degradation. The protestations from developers inevitably follow: why are we wasting time doing this? Why can’t they just upgrade their browser? It’s people like them that hold the Web back. Aren’t they aware of how insecure their shitty browser is? We should be like Google and Facebook and only support versions that are n-1. This is bullshit!

Gracefully degrading a website that has been worked on for weeks, in order to ensure it’s functional in browsers not considered modern enough to deserve a developer’s effort, is a painful thing to do. I’ve been there, and I didn’t enjoy it. The subsequent drop in productivity and morale is something managers pick up on. The next time the decision comes around whether or not to include a browser in a test plan, justification is required. If the browser doesn’t represent a sufficiently lucrative market, it’s out.

I’ll say right now that what follows has never been stated explicitly at my place of work, but I get the feeling that in terms of prioritisation, accessibility is put in the same box as browser support. How many people does this affect? What percentage of our target demographic do they represent? Where’s the cost-benefit analysis?

Stick vs Carrot

Our legal obligation to not substantially disadvantage users clearly hasn’t had enough clout to ensure inclusivity stayed in focus. There are no UK court cases that spring to mind in which a university was taken to task over the accessibility of its website. I suspect the attitude is much as it was when the Cookie Law came into effect: if we receive a complaint, the law gives us a reasonable amount of time to fix it, so we’ll worry about it when the time comes. And besides, the ICO isn’t going to be coming after universities, is it? It’ll be after the real villains.

The lack of any complaints fosters complacency: either the website is completely fine, or it’s not fine but we’re getting away with it.

There’s little understanding of what’s required to attain the all-important WCAG AA rating considered to be an acceptable standard. Someone will mention ARIA, and one look at the specification sends folk running for the hills. We have to learn this too? Yet another thing to add to the pile of cognitive load! We only just figured out responsive, and now this!

Like any new skill, it seems daunting from the outside.

Knowledge

While investigating how to proceed with improving the usability of our website, I found many books and articles recommending a mobile first approach. Then it became content first.

Conversely, we were using a waterfall process by which a static desktop-centric visual design would be created (by my manager) and then passed to me to build. There would be no downstream consultation, and no chance for upstream feedback because that might require a redesign, and there’d be no time, so just do what you can.

My priority would be reproducing the visual aspects of the design as faithfully as possible: like accessibility, performance wasn’t a consideration. I’d then connect the final templates to the CMS, and that would be passed to the content editors who would apply their own ideas of what a website should look like, pouring content into the pre-defined boxes.

As I read about responsive design workflow, the idea of starting with content, in the smallest viewport, and then layering markup and typography and styles and behaviours around it seemed more and more sensible. We had no idea what device users might have: it could be a smart phone, or a tablet, or a phablet, or a feature phone, or a games console. By this point, even toasters were in the mix. Making something that would work in all of these contexts was less about individual devices and more about what they all had in common.

As we started to gear up for the responsive project, I realised that in order to improve the usability of our website for the largest number of users, on the widest variety of devices, in the least amount of time, and with a minimum of resource, we had to start with the marked-up content and ensure that the foundation was solid. Pretty basic stuff. All users would benefit from that regardless of device. We could then move on to the delightful aspects of the project, so long as we were mindful about it. And the key benefit to doing it this way was that less capable devices would work perfectly well, without us having to dick around degrading our codebase, gracefully or otherwise.

I later learned the name for this approach: progressive enhancement.

I also started seeing similarities between the recipe for progressive enhancement and ways of improving inclusivity. It boiled down to using the inherent benefits of the language and building upon them with care. Instead of adorning a <div> with complex JavaScript and CSS to make it look and behave like a Prospectus search box, we could use standard HTML form elements like <input> and <label> - and it would take a lot less time and effort!

In other words, it started looking less like a case of making the website responsive, or making it accessible, and more about keeping it accessible and responsive.

Mind Blown

Background image courtesy of Sven Geier, with thanks.

This change of mindset is the most difficult thing to communicate.

I had these revelations on the basis of the journey I was on, from A to B to C. It made sense each step of the way, because each new step was informed by the one before. However, persuading others of the benefits of C was not so straightforward. They hadn’t been on the journey with me through A or B, so they only had my word to go on.

I bought books for the team, and shared links to videos and blog posts, and evangelised at every opportunity, so that they could find a quicker path to C than I’d had, to realise that prioritising inclusivity wasn’t as scary or difficult or time consuming as they might think; but sometimes a horse just won’t drink. Sometimes the horse just isn’t that thirsty. Sometimes the horse is downright suspicious of the water.

Now I’ll admit it’s maybe a big ask: shifting our methodology 180 degrees, and turning the tried-and-tested waterfall process on its head. In this brave new world, the high-fidelity representation of what the thing should look like - the stuff everyone was used to seeing right at the start - would be revealed gradually throughout the process, as a result of having first determined what the users would need, and how we’d get that to them, and how to enable all our users to interact with the content. Or put another way, form following function.

And then I started talking about what would happen if JavaScript wasn’t available, and everything went nuts.

Building Ourselves vs Downloading

One of the best ways of saving time during a build is by identifying a pattern or problem that has been solved already, and reusing that solution. The web community is amazingly generous with its knowledge, and there’s no shortage of ready-made solutions just a npm install away.

As with any third-party solution, you make an implicit agreement to align yourself not only with the author’s update cycle, but also their philosophy. Jeremy Keith explains it very well: some solutions are more opinionated than others.

If the author hasn’t considered the accessibility of what they’ve built, we inherit that omission. It becomes our omission. It’s rare to find ready-made solutions that have been progressively enhanced, and have accessibility as a core value, so it becomes a choice of whether to spend more time looking, or diving into the code to make it do what we need, or abandoning the search and building it ourselves.

Reinventing the wheel is a phrase I’ve heard quite often, usually in exasperated tones, and it’s used to shut down the suggestion that we should spend time creating something ourselves that will fit our needs and environment, when we could amend our expectations of what we need and adopt someone else’s solution. Again, time is the primary factor here.

I recently learned of the counterpoint to that phrase: not invented here. It describes the notion that only stuff we build ourselves is thought to be any good, for whatever reason. I’ve thought a great deal about whether that’s the case here, if that’s what I suffer from, and came to the conclusion that it’s not: the stuff we build could be fundamentally deficient - as past experience has shown. Equally, there could be resources being worked on in the community right now that I’d adopt in a heartbeat, so long as they tick all the boxes.

However, what I realised is that our team hasn’t collectively agreed upon what those boxes should be.

Design Principles

Throughout this journey I’ve been on for the past few years, the common thread has been differences of opinion with managers about what they’ve chosen to prioritise. Each time I’ve met with resistance, I’ve tried to understand the reason for it.

Middle managers are the liaison between us worker drones and the queen bees of senior management. They’re the ones who attend the meetings that could’ve been emails, the ones trying to connect emerging requirements coming from senior management to what’s actually possible.

Senior management represents the business, and the various demands put upon it from all sides, and they don’t get to the position they’re in without being able to apply pressure to make things happen. I’ve experienced this myself. I gave a presentation about an upcoming upgrade of our in-house events system, and I highlighted all the benefits the business would soon be reaping. At the end of the presentation, I answered a few questions, and just as I was about to wrap up, the senior manager in the room looked over his glasses at me and said and it will be ready in two weeks time. There was the slightest hint of an inflection in the sentence, but it wasn’t a question; it was a statement. His mouth was smiling but his eyes weren’t, as if he was practicing a Jedi mind trick.

I suspect that’s the thin end of the wedge when it comes to management coercion, and that’s what my line managers have to cope with on a regular basis. It’s possible that one of the factors contributing to their reluctance to change priorities is a lack of confidence that they’ll be able to make the case for what is perceived to be additional work of an unknown quantity, which will take additional time, which will stretch milestones, and jeopardise project plans.

Providing middle managers with the information they need to get the message across in a language that senior managers will respond to is challenging, but not impossible.

A couple of years ago the University published its five-year strategic plan, which outlined the values of the institution and its aims for the coming years. The cynical part of me immediately thought it was more marketing wank to make the University sound forward-looking, but once I got past that, I realised that if our team described what we were trying to do in those terms, aligned with the concepts within the strategic plan, that would be all the justification we’d need to answer any challenge. The strategic plan even had words like diversity, equality, and even inclusivity - bingo!

Taking it one step further, the strategic plan could be viewed as a set of design principles. Having recently seen sets of design principles from the Government Digital Service and the BBC, I started thinking that perhaps we should have a set of our own. After all, if we enshrined our values in a document, we could refer to it any time there was a conflict of interests, and we could refer others to it when they asked why we prioritised work in the way we did. Sounds dreamy, right?

I dutifully took the idea to my managers: guess what happened next.

Feedback