The web community talks a lot about best practices in design and development: methodologies that are key to reaching and retaining users, considerate design habits, and areas that we as a community should focus on.
But let’s be honest—there are a lot of areas to focus on. We need to put users first, content first, and mobile first. We need to design for accessibility, performance, and empathy. We need to tune and test our work across many devices and browsers. Our content needs to grab user attention, speak inclusively, and employ appropriate keywords for SEO optimization. We should write semantic markup and comment our code for the developers who come after us.
Along with the web landscape, the expectations for our work have matured significantly over the last couple of decades. It’s a lot to keep track of, whether you’ve been working on the web for 20 years or only 20 months.
If those expectations feel daunting to those of us who live and breathe web development every day, imagine how foreign all of these concepts are for the clients who hire us to build a site or an app. They rely on us to be the experts who prioritize these best practices. But time and again, we fail our clients.
I’ve been working closely with development vendor partners and other industry professionals for a number of years. As I speak with development shops and ask about their code standards, workflows, and methods for maintaining consistency and best practices across distributed development teams, I’m continually astonished to hear that often, most of the best practices I listed in the first paragraph are not part of any development project unless the client specifically asks for them.
Think about that.
Development shops are relying on the communications team at a finance agency to know that they should request their code be optimized for performance or accessibility. I’m going to go out on a limb here and say that shouldn’t be the client’s job. We’re the experts; we understand web strategy and best practices—and it’s time we act like it. It’s time for us to stop talking about each of these principles in a blue-sky way and start implementing them as our core practices. Every time. By default.
Whether you work in an internal dev shop or for outside clients, you likely have clients whose focus is on achieving business goals. Clients come to you, the technical expert, to help them achieve their business goals in the best possible way. They may know a bit of web jargon that they can use to get the conversation started, but often they will focus on the superficial elements of the project. Just about every client will worry more about their hero images and color palette than about any other piece of their project. That’s not going to change. That’s okay. It’s okay because they are not the web experts. That’s not their job. That’s your job.
If I want to build a house, I’m going to hire experts to design and build that house. I will have to rely on architects, builders, and contractors to know what material to use for the foundation, where to construct load-bearing walls, and where to put the plumbing and electricity. I don’t know the building codes and requirements to ensure that my house will withstand a storm. I don’t even know what questions I would need to ask to find out. I need to rely on experts to design and build a structure that won’t fall down—and then I’ll spend my time picking out paint colors and finding a rug to tie the room together.
This analogy applies perfectly to web professionals. When our clients hire us, they count on us to architect something stable that meets industry standards and best practices. Our business clients won’t know what questions to ask or how to look into the code to confirm that it adheres to best practices. It’s up to us as web professionals to uphold design and development principles that will have a strong impact on the final product, yet are invisible to our clients. It’s those elements that our clients expect us to prioritize, and they don’t even know it. Just as we rely on architects and builders to construct houses on a solid foundation with a firm structure, so should we design our sites on a solid foundation of code.
If our work doesn’t follow these principles by default, we fail our clients#section2
So what do we prioritize, and how do we get there? If everything is critical, then nothing is. While our clients concentrate on colors and images (and, if we’re lucky, content), we need to concentrate on building a solid foundation that will deliver that content to end users beautifully, reliably, and efficiently. How should we go about developing that solid foundation? Our best bet is to prioritize a foundation of code that will help our message reach the broadest audience, across the majority of use cases. To get to the crux of a user-first development philosophy, we need to find the principles that have the most impact, but aren’t yet implicit in our process.
At a minimum, all code written for general audiences should be:
- responsive
- accessible
- performant
More specifically, it’s not enough to pay lip service to those catch phrases to present yourself as a “serious” dev shop and stop there. Our responsive designs shouldn’t simply adjust the flow and size of elements depending on device width—they also need to consider loading different image sizes and background variants based on device needs. Accessible coding standards should be based on the more recent WCAG 2.0 (Level AA) standards, with the understanding that coding for universal access benefits all users, not just a small percentage (coupled with the understanding that companies whose sites don’t meet those standards are being sued for noncompliance). Performance optimization should think about how image sizes, scripts, and caching can improve page-load speed and decrease the total file size downloaded in every interaction.
Do each of these take time? Sure they do. Development teams may even need additional training, and large teams will need to be prescriptive about how that can be integrated into established workflows. But the more these principles are built into the core functions of all of our products, the less time they will take, and the better all of our services will be.
How do we get there?#section3
In the long run, we need to adjust our workflows so that both front-end and backend developers build these best practices into their default coding processes and methodologies. They should be part of our company cultures, our interview screenings, our value statements, our QA testing scripts, and our code validations. Just like no one would think of building a website layout using tables and 1px spacer images anymore (shout out to all the old-school webmasters out there), we should reach a point where it’s laughable to think of designing a fixed-width website, or creating an image upload prompt without an alt text field.
If you’re a freelance developer or a small agency, this change in philosophy or focus should be easier to achieve than if you are part of a larger agency. As with any time you and your team expand and mature your skillsets, you will want to evaluate how many extra hours you need to build into the initial learning curves of new practices. But again, each of these principles becomes faster and easier to achieve once they’re built into the workflow.
There is a wealth of books, blogs, checklists, and how-tos you can turn to for reference on designing responsively, making sites accessible, and tuning for performance. Existing responsive frameworks can act as a starting point for responsive development. After developing the overarching layout and flow, the main speed bumps for responsive content arise in the treatment of tables, images, and multimedia elements. You will need to plan to review and think through how your layouts will be presented at different breakpoints. A tool like embedresponsively.com can speed the process for external content embeds.
Many accessibility gaps can be filled by using semantic markup instead of making every element a div or a span. None of the accessible code requirements should be time hogs once a developer becomes familiar with them. The a11y Project’s Web Accessibility Checklist provides an easy way for front-end developers to review their overall code style and learn how to adjust it to be more accessible by default. In fact, writing truly semantic markup should speed CSS design time when it’s easier to target the elements you’re truly focused on.
The more you focus on meeting each of these principles in the early stages of new projects, the faster they will become your default way of developing, and the time spent on them will become a default part of the process.
Maintaining focus#section4
It’s one thing to tell your team that you want all the code they develop to be responsive, accessible, and performant. It’s another thing entirely to make sure it gets there. Whether you’re a solo developer or manage a team of developers, you will need systems in place to maintain focus. Make sure your developers have the knowledge required to implement the code and techniques that address these needs, and supplement with training when they don’t.
Write value statements. Post lists. Ask at every stage what can be added to the process to make sure these core principles are considered. When you hire new talent, you can add questions into the interview process to make sure your new team members are already up to speed and have the same values and commitment to quality from day one.
Include checkpoints within each stage of the design and development process to ensure your work continues to build toward a fully responsive, accessible, and performant end product. For example, you can adjust the design process to start with mobile wireframes to change team mindsets away from designing for desktop and then trying to backfill mobile and tablet layouts. Another checkpoint should be added when determining color palettes to test foreground and background color sets for accessible color contrast. Add in a step to run image files through a compressor before uploading any graphic assets. Ask designers to use webfonts responsibly, not reflexively. Set a performance budget, and build in steps for performance checks along the way. Soon, your team will simply “know” which features or practices tend to be performance hogs and which are lean. You will need to make sure testing and code reviews look for these things, too.
Nothing worth doing happens by accident. Every time we overlook our responsibilities as designers and developers because it’s faster to cut corners, our products suffer and our industry as a whole suffers. As web professionals, how we work and what we prioritize when no one’s looking make a difference in thousands of little ways to thousands of people we will never meet. Remember that. Our clients and our users are counting on us.
Thank you.
Over the years I have learned and observed all of the points you raise, more recently preached them too.
With that said though, I haven’t seen the contents of my mind so well put as with your article.
There is much wisdom to be found here, for the humble worker bee closing tickets to the best closing salesperson, as well as their manager and our clients.
Great stuff!
Thanks, David! If it helps you make your points internally, I’d love to hear about it!
Don’t get me wrong, it’s fantastic that you’re championing the best practices we should all aspire to.
But the commercial reality is often somewhat different. If the client doesn’t understand what is really meant by accessibility for example, and hasn’t asked for it, then increasing our costs because of it (because time = money) could mean we don’t even get the work to begin with.
The only real way we have to deal with this is to leave it out to start with to get the work, and if the client decides or can be convinced that they want it later (for a workable price) then we can include it as a chargeable extra. That won’t always (or often) happen though.
About: ‘..are not part of any development project unless the client specifically asks for them’
– it depends on the project type.
If the client is another software development company, and they are just renting developers for a specific project, in addition to their internal team, very often you have no say in what you do daily and how you do it..
I just wondered if it is All of our Responsibility to improve accessibility as a whole, by contributing to any open-source apps/plugins/themes we use so that we don’t make the changes ourselves?
Kendra, this is a unique eye-opener for me.
Also as Dave Wallace put it, that it really does gather up all the running thoughts about this, even more that it’s into just One Article!
Thank you for the post.
This is the reason why I keep note of these, because they live on for a long time.
Kind regards,
Mic
Michael, I understand that commercial reality. I face it too, and my team and I often brainstorm different ways to explain the full value of what we’re offering to clients, when much of that work is unseen. (I would love to hear how other shops are successfully communicating the value of this kind of work!) Part of the point I’m trying to make is that the burden of that is on us, not on the client. Responsive design, accessibility, and performance should be core principles, meaning they’re the non-negotiable underpinnings that ensure that our final products are serving both the clients and the visitors, even though they’re unseen. To leave them out is akin to building a home without a foundation.
When we aren’t building according to these principles, we’re giving our clients a sub-standard product, and everyone suffers. The visitor suffers a frustrating experience and leaves the site, in search of other solutions. The client suffers this loss but doesn’t even know that it’s happening. As a result, our whole industry suffers as the affect snowballs.
As you acknowledged, we all know a client isn’t going to come back later after the project is done, and ask you to remediate their website for accessibility – unless they get sued, in which case they’ll be paying for a lot more than just that remediation. It is much faster and easier to build a site with accessible markup and principles in the first place, as a default practice. I fully believe that coding that way doesn’t have to be more expensive in the long run.
Sumner, I agree! One of the best parts of our industry is that it’s filled with professionals who have a collaborative mindset, who know that a rising tide lifts all ships. Many open source projects do prioritize accessibility and responsive design (though I find it can be harder to get lean, performant code out of it). Our team has made some small accessibility contributions back to Drupal modules we use, and we are actively working on ways to contribute more.
In general I agree with most points, save one of the accessibility points. Getting subtitles, captions, and audio descriptions (which are often overlooked) done on video is not something that is easy, nor cheap. It’s simple to include those assets once they are created, but not creating them itself tends to be a business in itself. If a client does not understand the need for accessibility, and your competitor does not care about it and will just put up a video without them, then you’re likely going to have issues with justifying those costs to the client.
@Kendra what contributions have you made with Drupal and how did you achieve success in this? I have posted a bug on the Devel module saying that it was not appropriate for them to switch from a table-based output to divs for the semantic table that is output once “Display query log” is checked. The claim was that it was better for rendering/performance, but it greatly reduced the accessibility of the output.
You’re right, powrsurg, adding captions and descriptions to video is a huge lift. My focus for this article is on our duty in the underpinnings of the development work, not content-specific work such as video.
I can’t speak to all Drupal development. Indeed, different maintainers have different philosophies on what they prioritize and why. And just implementing a site using Drupal doesn’t mean it automagically meets all these criteria – but it does help raise the starting point.
To answer your question, when we’ve found accessibility issues with contributed modules we use, we have contributed fixes back. We’re also working on an accessibility checker plugin to the CKEditor WYSIWYG module for D7 (it’s already in D8, but we backported it to D7). While we’re a little late to the contrib-party, our team has prioritized giving back to the community more in the next year. https://www.drupal.org/state-of-georgia