TL;DR
Accessibility, Analytics, and SEO are the last things many of us think about when building out new website features, but they should be among the first things we address.
We should be developing website features with analytics, accessibility, and SEO in mind from the start. Every initial feature discussion should answer the questions “How do you want to track interactions with this feature?”, “How will users with a screenreader, keyboard only interface, or vision impairment interact with this feature?”, and “How will this change affect how search engines display links to our pages?”.
I often find that companies spend thousands of dollars building new features for their sites that simply won’t meet accessibility standards. They then face lawsuits with stiff penalties and have to reinvest in order to build the same feature again from scratch.
Many of these same companies also end up in a situation where they make changes but have no way of determining how their visitors are reacting. They may have assumed that something was going to be tracked by default only to find that it is not.
Then after the change is live for a bit they find that their visitor count is plummeting because Google isn’t finding their content anymore. All of these behaviors should be treated as part of the basic requirements of new features and gathered at the beginning, just like any other visual or behavioral requirement.
What’s Different?
In my experience the analytics and SEO teams are brought on at the end of a project to “add tracking” and “shore up SEO”. The Accessibility compliance check is done during QA (if it is done at all). With deadlines and pressure to produce, this is often too late to create meaningful change.
Process
I like to use a requirement checklist during initial requirements gathering meetings to ensure that all points are accounted for. I think the following is a good start:
- Accessibility
- Analytics
- SEO
- Screen Size
- Touch
- Security
This checklist is a tool. You should build tools into your process and iteratively improve them to meet your team’s specific needs. A complete list will be longer and include items specific to your organization. You may add and remove items over time as your priorities change.
Mobile First (or Mobile Friendly) and Security
Please note that this is assuming you’re already doing mobile first (or at least mobile friendly) design, accounting for screen size variation and touch interactions. It also assumes that you have your security team involved on more sensitive features. If you aren’t doing those things they should be on your radar from the beginning as well!
Accessibility
“Web accessibility is the inclusive practice of ensuring there are no barriers that prevent interaction with, or access to websites, by people with disabilities. When sites are correctly designed, developed and edited, generally all users have equal access to information and functionality.”
–Wikipedia
Web accessibility compliance is legally required for websites targeting customers in most parts of the world. Not meeting accessibility requirements can make your organization the target of lawsuits and bad press.
Accessibility should be focused on first for a number of reasons. Some designs simply do not meet visual accessibility requirements. If your design features low text to background contrast, confusing non-native interactables, or other issues it may need an extensive rework before requirements gathering can begin. If the design has not been created yet all of these things can be addressed as part of the requirements gathering process, avoiding rework in the design stage.
Working to meet non-visual accessibility requirements can require significant changes to markup, which then may affect how the css and js are written on the frontend, and may also change how the html is generated on the backend. The need for additional copy for screen readers to read also needs to be identified, which may change how that copy is stored on the backend.
The great thing about accessibility compliance is that it can and should mean a more usable site for everyone! Using semantic markup for accessibility compliance may even improve your SEO.
Analytics
“Web analytics is the measurement, collection, analysis and reporting of web data for purposes of understanding and optimizing web usage.”
–Wikipedia
Web analytics services are the platforms that tell you how many people are visiting your website, what they’re doing when they get there, and how long they’re sticking around. Knowing what your users are doing can help you improve your site which can benefit both you and your customers. You can find ways to make your site easier to use and thus make it easier for your customers to buy your products and services.
Addressing analytics early can do two things for your requirements gathering process. First, it will let the developers know where they should add hooks in the behavior logic for tracking user interactions. This means that the developers can add them as they go rather than needing to modify the JavaScript late in the development cycle, potentially introducing defects right before release. Second, discussing analytics early can help designers and stake holders determine success criteria for the new feature. Some new visual element may be designed to make users find where they are going next, which might actually reduce the amount of time a successful visit takes.
Bringing up analytics requirements early in the process can also make the costs of integrating the service more apparent. If you are adding analytics in later (potentially even after release!) then it may not be obvious that adding 3 additional analytics services is quadrupling the cost of production.
SEO
“Search engine optimization (SEO) is the process of affecting the online visibility of a website or a web page in a web search engine’s unpaid results.”
–Wikipedia
In common conversation, I also regularly hear “SEO” used to simply refer to a site or page’s search rank.
Addressing SEO early comes with many of the same benefits as addressing accessibility early. Your markup or even page layout may need to change to meet certain SEO standards. You may need additional non-visual copy that needs to be coded for. It is even possible that a core part of the new feature’s behavior is not crawlable, which may mean that you need to rework the design itself, or design a secondary element to compensate.
Conclusion
So with those benefits in mind, strive to address accessibility, analytics, and SEO as early as possible in your development life cycle. To tackle this, during requirements gathering you can use the basic checklist I provided, create your own, or add to one that you already have!
Leave a Reply