“How do I test my entire site?” is one of the most frequent questions we get from customers and potential customers. There are a variety of ways to do this with Tenon. You can use the Spider, or you can populate a project with a Sitemap.xml file. Of the two approaches, I personally advocate for using a Sitemap.xml file. Both approaches have their advantages and disadvantages. One disadvantage that they both share is that there’s no method for determining which pages are the most important pages on the site.
What is your goal?
When it comes to testing an entire site, the question you must ask is: “Why?”. In my opinion there are three primary reasons to do accessibility testing:
- Detect accessibility problems that you intend to fix
- Gauge your site’s overall level of accessibility
- Monitor for new accessibility problems on a site that has a lot of new content.
You may have other reasons for testing your site, but I think of these as the most common ones. Unfortunately, spidering is less-than-ideal for anything other than the 2nd goal: “Gauge your site’s overall level of accessibility”. Spidering of a large site is always going to result in an overwhelmingly large number of issues, possibly repetitive in nature, that in-practice few people end up addressing. When it comes to the 3rd goal, we feel that Site Monitors are a more effective approach. But let’s talk about that 1st goal: Detecting accessibility problems that you intend to fix.
Target and prioritize remediation based on traffic
Both volume and location of issues are two prioritization factors I’ve been discussing for several years now. In short: the more likely it is that a user with disabilities will encounter a problem, the more important it is for us to fix the problem. Let’s walk through using Google Analytics and Tenon to detect these most frequent issues.
Get a list of your most frequently seen URLs from Google Analytics
The first step in this process, of course, is to get a list of your most frequently visited pages. We’ll be using Google Analytics for that purpose. Log into Google Analytics and navigate to the site you want to work with. I’ll be using my personal website in this example.
Once you’re on the landing page for the site you want to work with, scroll down to the table with a heading above it that says “What pages do your users visit?”. Once there, activate the link under the table that says “Pages report”
That takes you to the Pages Report. The pages report provides a list of all of the pages on your site. It is a highly interactive page, that shows a chart of page views above the list of pages. The pages themselves are listed in a table with various columns such as “Pageviews”, “Unique Pageviews”, “Avg. time on page”, etc.
Above the chart is a link that allows you to export the report. Before exporting, ensure that the table below is showing the proper data you want to export. For instance, I sorted the table by “Unique pageviews” prior to exporting. Then, I selected to export the information to an Excel format.
The 2nd tab of the Worksheet is labelled “Dataset1”. This contains the data you want to work with. If you scroll to the bottom of the list of pages, the very last row contains totals for each column. Take note of the number for “Total Pageviews”. Take that number and calculate what 90% of that number is. For instance, for my site, the total was 563. 90% of 563 is 506. The goal for this exercise is to test the pages that represent the top 90% of all traffic. Quite simply, all you do is highlight the cells in the “Unique Pageviews” column until the “Sum” in the status bar of Excel matches your 90% number.
For my site, the top 44 URLs (out of 85 shown in Analytics) got exactly 90% of the traffic on my site. The next step is to construct the actual list of URLs. With Google Analytics, the “Page” column shows a root-relative path to the URL. What we want is the fully-qualified URL. That is, the protocol, hostname, and URL path. To do so, all we need is a little Excel-fu. We use the CONCATENATE() function in Excel to do this. Add a new column to the left of “Page” to hold the concatenated value.
From there, all you need to do is copy & paste that function down the rest of that new column to generate the full URLs for testing.
Once you’ve generated the URLs, it is time to get them tested. Log into Tenon, navigate to “Projects” and then activate the button to “Add a new project”. From there, all you need to do is give the Project a name, and paste in the URLs you want to test!
Once you’ve pasted the URLs you want to test, fill out the rest of the form to dictate your testing preferences and submit the form. The URLs will be added to the Test Queue and be tested right away. Once tested, the results will be available in your Dashboard for that project.
Why this approach is awesome
Ideally you’d be able to test every page on your site quickly, locate all of the issues reported, fix all of them, and deploy the fixes right away. Unfortunately, such an expectation just isn’t realistic. Site owners have multiple concerns that extend beyond accessibility and often limited resources must be allocated to handle all of these concerns. As I’ve said on my personal blog, not all accessibility problems are equal. While it would be great for every site on the Web to be perfectly accessible, we need to realize that they aren’t and that means we need to focus on providing the maximum benefit quickly. Using the approach I’ve described above helps to do that. By focusing on the most accessed URLs on the site, we’re able to aggressively deal with those accessibility problems that are most likely to impact a larger number of our users. On a large site with a ton of traffic there will still be many opportunities for users to have challenges. Our Point-of-contact service can help in those cases. But nothing will have a higher positive impact to end users like prioritizing your testing to the most trafficked areas.