Web Accessibility - AMP - Advanced website test using the Accessibility Management Platform (AMP)

How to conduct an advanced web accessibility test using the Accessibility Management Platform (AMP).

The Accessibility Management Platform (AMP) service is ending on July 31, 2019.

In order to preserve your accessibility testing reports, we recommend that you retrieve your reports prior to July 31. 

See Web Accessibility - AMP - Service ending on July 31, 2019 for instructions on how to download your data, along with information about why the service is ending, what to use instead, and what's next for accessibility testing tools at UW–Madison. 

For assistance please contact Sandi Arendalkowski, Accessibility Lead in the Center for Digital Accessibility & User Experience at sandi.arendalkowski@wisc.edu.

If you wish to test more than one page at a time, we recommend using the Accessibility Management Platform (AMP) website to do so.

To do so using the website you’ll need to first create a test, with one or more pages (called modules in the tool).

To begin you’ll first need to select an existing project or create a new one.

Having selected a project, select the Tests tab on the main project page.

Image of AMP dashboard with Project name and selection checkbox.

From here you can view any existing tests as well as create a new one by clicking on the ‘Create New Test’ link.

Currently, the only platforms we can test against are websites, so select ‘Web,’ followed by the ‘Make it happen’ button.

Image of technology platform selected - web.

Next, you can select how deep of testing you want. Keeping the default of ‘High Level Audit’ is sufficient for most testing.

Image of the 'high level audit' test selected.

In the next step you can determine what you would like to test.

Image of test type spider selected.

  • The default option of Spider will allow you to enter a start page, configure the crawl depth, and setup some basic path restrictions.
  • The Manual option will allow you to manually add items to be tested. This requires more work, but allows you to selectively test pages.
    • If you’re only testing a few pages, you may want to try the AMP Toolbar for Firefox instead.

For a basic test, keeping the default of Spider is sufficient, which we’ll focus on here.

The next section of a Spider test will allow you to configure the test.

Image of test configuration classic selected. This configuration description is, AMP will create modules for pages it finds starting at a given URL.

The default option of Classic will spider your site starting from a specific page, just like a search engine. If all of the pages you wish to test are accessible via a standard crawl, this option would be sufficient.

If the site requires authentication you’ll need to first create and upload a Selenium test. If you’re testing only a few pages, you may want to use the AMP Toolbar instead.

You can also upload a CSV files that contains a list of URLs to test. This option would be beneficial if you only want to test some pages, or if not all pages are accessible via a standard crawl of your site.

Enter a unique Test Name in the corresponding field, change the Report Owner as necessary, and then either enter a Start URL (such as the website’s home page, or section home page) or upload a CSV file in the correct format (if selecting CSV).

Tests can be automatically run via the scheduling option.

Image of test scheduling optional setting. With this feature you can schedule your tests and set recurrences.

Selecting this will create a new report when the test runs. This will allow you to see how your site improves over time, as well as keep an eye out for any breaking changes.

Image of multiple report rows overtime and their test score percentages.

If performing a crawl of the site you’ll be able to set the maximum number of pages tested, depth, as well as page filtering.

Image of advanced test configuration optional settings to allow the user to choose Path Restriction, Host Restriction, or Domain Restriction for scope setting.

If you wish to crawl your entire site, changing the maximum page count and depth, while keeping the rest as default, should be sufficient. The CSV option will allow you to set the XPath Exclusions only. These options are documented further below.

Once you have finished configuring the test press the 'Make it happen' button to create the test.

You’ll now be presented with the new test, with no results. Click the ‘Run Test’ link in the top left corner of the page to start the test.

Image of new test with no logged results. Click the run test link in the top left corner of the page to kick off test.

You can watch the progress of the test in the upper right corner of the page by clicking on the plus sign next to the ‘Testing in Progress’ text.

Once the test has finished running you can refresh the test page to see the results as a report, where you can dig into your results. You can also find the results report in the main project as well.

What do the Advanced Test Configuration options do?

  • Max. Page Count
    Limits the number of pages that will be crawled.
  • Maximum Depth
    Limits how deep the crawler will go. As the crawler finds links on a page, the depth of that page is increased by one.
  • Max. Argument Count
    Limits the number of arguments in a URL. This might be helpful for pages that allow for filtering.
  • Negative Filters
    Excludes pages from being checked that match the filter. This could be used to exclude sections of the site that would not need to be checked.
  • Positive Filters
    Includes pages to be checked. Might include pages that would otherwise be excluded.
  • XPath Exclusions
    Excludes part of the HTML from being checked. For example, if you have a footer that should be skipped, you can write an XPath statement to exclude it.
  • Scope
    Assuming a start URL of http://www.wisc.edu/academics/ :
    • Path Restriction
      URLs will only be crawled and tested if they are at or below the start URL.
      Using the example above, http://www.wisc.edu/academics/majors.php would be tested, while http://bus.wisc.edu/ would not.
    • Host Restriction
      URLs will only be crawled and tested if they have the same host name.
      Using the example above, http://www.wisc.edu/admissions/ would be tested, while http://www.admissions.wisc.edu/ would not.
    • Domain Restriction
      URLs will only be crawled and tested if they have the same domain.
      Using the example above, http://www.admissions.wisc.edu/ would be tested, while https://www.google.com/ would not.

See Also:

Keywords:web, accessibility, amp, accessibility management platform, ssb bart group, accessibility test, web accessibility test, accessibility testing, detailed, advanced   Doc ID:50858
Owner:Sandi A.Group:Accessibility
Created:2015-04-27 09:49 CDTUpdated:2019-07-17 14:58 CDT
Sites:Accessibility, DoIT Help Desk
Feedback:  1   1