AMP New User Orientation - 3 - Crawling Tests
Hi. And welcome to the third AMP New User Training Orientation Session. Today's focus is going to be creating a crawling test in AMP. As a standard AMP user, you have the ability to create a test that will crawl through an existing web site and test the different pages it comes across, based on the configuration settings you specified for accessibility compliance.
Usually, a crawling test is ideal for testing nonauthenticated public content, especially when you have a large potential dataset that you want to crawl across to understand what content you have in your site and where that content is, as well as how accessible that content is.
Within the system, crawling tests are always grouped within a project. And projects are a critical component of staying organized in AMP. Right now, we're starting from my User Dashboard, which is the user homepage in AMP. And we can always navigate to the User Dashboard by selecting the Dashboard tab in our primary navigation tab options. This will always return us to our User Dashboard.
From our User Dashboard, the first thing we'll want to do is either access an existing project, which we can do through our Projects link in the secondary navigation bar, where we can select either recent projects that we've accessed or view all the projects that we have access to. We could also, depending on our widget configuration, see our projects within our User Dashboard itself, which is how I have this configured.
Now, because all of our tests are always stored inside of a project, when we're referring to our crawling test, which can be saved and run on a recurring basis, I can either navigate into one of my existing projects, through one of the pathways we've discussed. Or I can always create a new project.
You can always create a new project by navigating to your Projects link in the secondary navigation bar and select View All Projects. From within that View All Projects table, which will display all the projects that you as a user have access to, you'll find a Creative Project link in the table header.
When you select this Create Project link, it's going to launch our Create Project modal. To create a project, all we have to do is give this project a name. I strongly recommend taking a moment to consider what you're naming your project and make sure that that name makes it easy to identify what content has been tested within this project.
At the same time, it's always a good idea to think about what content you're going to test within a project, because projects should generally be used to test related to one set of digital content, such as a website, or for repeated testing of one specific test set, such as a representative sample of key pages and templates, which would allow you to track your changing Compliance Score over that specific test set, over time, within your project.
In short, we want to make sure that we leverage projects to stay organized in AMP. And that means making sure that any test data related to a specific set of content is stored within the relevant project. This will make it easy to navigate into any project or even the report level to find the specific results you are looking for, or anybody you've shared this project, or any other reports in the project, with.
Now, that I've opened up my Create Project modal, I'm just going to make sure that I give this a concise name. And for us, I'm going to call this the AMP New User Orientation Project. Just select Make It Happen. And when I select Make It Happen, I will have created a new project, and I will be navigated to the Project Dashboard for that new project. So we can see from my page title, I'm in my AMP New User Orientation Project Dashboard.
By default, or when we create a new project for the first time, we're going to load up the default widget set. But now that we're in a project, we can go ahead and we can create our first crawling test. And we can do so by looking to our secondary navigation bar, directly beneath our primary navigation tabs, and selecting the Test link.
When I select the Test link, it'll bring me to a table that displays all the tests currently saved within this project. Because we just created this project and we don't have any test data in there yet, we're going to see our table is empty. But in the table header, we can select to Create New Test link and activate, or navigate into, our Test Creation workflow.
When we navigate into our Test Configuration workflow, we're going to see that our first option is actually to pick between a classic test, this is where we're going to define a single starting point and then a couple of configuration parameters and AMP will crawl through the site based on the configurations we provided and generate a report with the results of that testing.
We also have the option to upload a CSV file. If we upload a CSV file, we can tell AMP to either test only the URL in that CSV file, or we can tell AMP to create one test for each URL, in which case we can create a bulk set of classic crawls all at once.
I've selected the CSV tab so we could look in here for one second, because you will find that there is a link to download the template directly on this test configuration page, which allows you to download a CSV file with a template that you can populate with a list of URLs. You're going to create your single test for testing a batch set of pages or creating one test for each URL, which allows you to create a bulk set of classic tests at once.
Because the configuration parameters are related to a CSV file are also part of the classic, we're going to navigate back to our classic workflow. And this is the most typical workflow when testing a specific or individual dataset.
Within classic, I'm going to find my first configuration option is Test Name This is just what we want to name the test. But it'll also be the name of any reports generated from this test, which will be appended with the date the test was run. I'm going to go ahead today and I'm going to test the National Park Service site. So I'm just going to call this Crawling Test of NPS, National Park Service, Main Site.
Beneath our Test Name, we have our Report Owner dropdown. Anybody who has permissions to the project that we're currently in can be the Report Owner. Currently, only I have permissions to that project. So I will be the only option in this list and will be the Report Owner. The Report Owner is the user specified as having ownership of any reports generated from this test. And it's assigned the responsibility of manual testing for any modules within that report.
Beneath the Report Owner field, we have our Start URL field. And the Start URL field is where I'm going to provide the starting point, or the starting address, for any crawl I want to do. In this case, because we're testing the National Park Service site, I want to include the National Park Service.
Or I want to provide the National Park Service homepage, which is You do want to make sure you include your http or https prefix whenever you're providing the starting URL for an AMP crawl.
One other thing to keep in mind is that AMP crawls render the page fully in a browser and we test the rendered DOM, which ensures that we're testing the most accurate end user experience.
As a result, we do need to be able to render the page fully in the browser to test it, which means that pages on an internet, unless they've been whitelisted, or pages behind authentication, are generally not able to be tested with an AMP crawl. AMP crawls are great for testing publicly facing content and being able to test across wide swaths or targeting specific sections of that publicly facing content.
Beneath our starting URL, we do have our Browser Emulation field. As I just mentioned, AMP renders each page it tests fully in a browser and tests the rendered DOM. We allow you to choose whether you want that page emulated in Firefox, Chrome, Internet Explorer, or Safari, if you're testing for desktop environments.
But we also provide Chrome, iPad Mini 4, and iPhone 6 environments, if you want to test in a mobile environment. So if you have responsive web design content or mobile standalone content, you can test it in that environment through an AMP crawl. Today, I'm just going to leave this on Firefox.
Directly beneath our browser emulation option, you're going to find your Max Page Count. The Max Page Count allows you to specify how many pages you want AMP to test as part of this crawl before it considers the crawl complete. By default, this will set to 10. But if you select the dropdown, you'll see you have options between 10 and 5,000, 5,000 being the upper range default value.
Now, generally speaking, we do recommend testing between 25 and 250 pages at a time, as larger crawls can provide so much information and have so many violations in them they can be harder to actually take action on.
Generally, 25 to 250 modules is your sweet spot and we certainly recommend building your crawling test to target specific subdirectories or sections of a site and potentially having multiple crawling tests per site. This allows you to have a clear understanding of the accessibility for each section of the site, as well as understanding the overall site accessibility at the project level.
Beneath your Maximum Page Count, you do have a Published Document Inventory option. This is a simple checkbox. And it allows you to enable or disable whether or not you want AMP to create a catalog of any hosted documents that are found while we crawl through the site. If you have it enabled, there'll be a Document Inventory option available inside your AMP report. And you'll be able to see a list of all those hosted documents.
Then, we have a couple of optional configuration settings. We do have the ability to run this test on a reoccurring schedule. So we can specify a starting date and time for a reoccurring crawl. And then, we can specify Reoccurrence Rate. This will default to an on-demand spider, which means we have to run this crawl manually. But if we specified a starting date and time, we could go in and set a Reoccurrence Rate of daily, weekly, monthly, quarterly, or yearly to run this test on a recurring schedule.
Additionally, we have Advanced Test Configurations that are also optional. The default values will allow us to save this crawling test and run it, but we do get a number of additional Advanced Configuration Settings. We can control things like the depth, or how far away from the starting URL, do we want the system to go, which defaults to 5.
The next option is our Maximum Argument Count. The Max Argument Count allows you to tell the system or set a limit in the system for how many pages with the same template should we test. This is specific for CMS systems that leverage an Argument Count structure in the URL to identify which template a page uses.
But if we are testing content in a CMS system that uses an Argument Count to identify the templates, we can restrict how many pages per template are tested. This helps us reduce our overall module count in the report, while ensuring that we're testing a clear representative sample of the different templates that may make up the site.
Next, we have some more advanced user features negative and positive filters allow a user familiar with regular expressions to use regular expressions to augment the crawl, negative filters to exclude content, or positive filters to include content.
Additionally, the XPath Exclusions field allows you to identify specific elements within your site that you'd like to exclude for testing. You can exclude those elements by supplying the XPath Directory for those elements in your page. For example, you could exclude a Footer in a site from being tested.
Lastly, we allow you to define the scope of the crawl. By default, it'll restrict to a Path Restriction, which requires the full path of your start URL on every page it comes across for it to test those pages. Host Restriction is less restrictive and requires the host from your start URL to be present on each page. And Domain Restriction is the least restrictive, which requires just the domain to be the same for any page it comes across to test that page.
I'll leave this at Path Restriction today and I'm going to select to Make It Happen to save my test. Because I created this test as an on-demand test, I'll have the Run Test link in my test the actions pane to the upper left of the page. When I select Run Test, we're then going to initiate this crawl and it's going to start crawling to the National Park Service site, testing the pages it comes across based on the configuration settings we specified, and generating a report with the results.
On the upper right hand side of the screen, we'll see our Testing Queue drops down to allow us to track the status of this test. We can see right now, it's rapidly moving through its crawl the National Park Service site and once this crawl is complete, it's actually going to give me a link in my Testing Queue dropdown to the report that was generated from this test. We've generated a report. And we've found an 83% Compliance Score for that test.
Thank you so much for taking the time to learn more about how we create a crawling test in AMP. We hope you'll join us in our fourth training session, Using the Access Assistant 2.0 Browser Toolbars.