An AUL accessibility test

  • Involves testing by individuals with disabilities on one or more platforms (Windows, macOS, iOS, Android) with a variety of assistive technologies.
  • The scope of testing is determined by the needs of the customer and the complexity of the system being tested.  

Testing timeframes

Timelines may vary based on the length of our testing queue and availability of our testers, but the usual turnaround times are:

  • For simple websites and applications, 2 to 3 days.  
  • For complex websites and applications,  2 to 3 weeks. 
  • For particularly large projects (for example, Google Apps for Education or Canvas), the turnaround may be 1 to 2 months.

Once testing is complete, the lab will provide a report documenting the findings. Please review the sample test report (Google Doc) for an idea of what is encompassed in a report document.  We can also customize our reporting to fit your needs (e.g. narrative report, spreadsheet, list of issues, video demonstration).

To request testing with AUL, please contact us at AUL@Colorado.EDU. You can also review the usual workflow between the lab and the client (shown further down the page) before contacting us so you have a good idea of what to expect.

Testing technology

The AUL staff includes individuals with disabilities who utilize different methods for access as well as different assistive technologies.  The AUL keeps all of our systems up to date to ensure we’re testing with the most current technologies. If you need a test with older technology, please email us and check the availability. 

The lab tests using all major operating systems (desktop and mobile) using the most up-to-date assistive technologies.

Testing workflow

All testing follows a standard workflow. Please review the following to see the three stages of what happens before, during, and after testing:

Before testing

  • You will meet with an AUL representative to answer pre testing questions
  • We will develop a specialized script for testers (Google Doc) with language that makes sense to the tester (e.g. replacing visual-based instructions with navigation-based instructions).
    • If not a CU Boulder entity please request access to the sample script from AUL@Colorado.EDU.
  • ​We will schedule testers for testing sessions.

During testing

  • We will conduct both supervised (using a sighted observer) and unsupervised testing, following a strict testing script.
  • You will have a representative on call to address unexpected problems (access denied, data reset, login expired, etc).
  • We can update you on how the testing is going and share early impressions of the project's accessibility, If needed. 
  • We will compile the test report and group problems by severity, starting with the blocking issues that render the application inaccessible, and ending with usability problems.
  • We can relate all accessibility problems to the sections and subsections of the WCAG standards, if needed.

After testing

  • We will deliver the final report to the customer (generally as a PDF or a Google Doc unless another format is requested by the customer). 
  • We can offer video recordings and live demos to showcase the issues.
  • We strongly recommend live demos, especially for service owners and developers with limited accessibility knowledge.
  • We can make recommendations on how to improve the usability of problematic elements (at the UX level rather than the coding level).
  • We can provide additional testing, as needed, after the developer attempts to correct the reported issues.
  • You should fill out our feedback form to tell us how we did and how we can improve.

What AUL doesn't do

It is also important to note that there are a few things that the AUL will not be able to do:

  • reveal the identity of testers.
  • make decisions to launch or stop a service - we can only provide recommendations and evaluations about what we believe to be the best course of action.
  • correct the application's source code to remediate the encountered issues.