Skip to Content

Frequently Asked Questions

This page provides answers to common questions about ANDI and offers troubleshooting tips.


Favorites/Bookmarks Bar has been disabled/hidden

If a web application has disabled the toolbar or favorites/bookmarks menu, and ANDI cannot be launched because the favorites/bookmarks bar cannot be accessed, try one of these workarounds:

  1. Press F10
  2. Using Firefox or Internet Explorer...
    • Right click on the page or press Shift + F10
    • Firefox: Select "View Page Info"
    • IE: Select "Properties"
    • Click next to Address (URL), press CTRL + A to select the full url
    • CTRL + C to copy the url
    • Open a new browser window paste the url into the address field, press enter
  3. If using IE, press CTRL + N to open a new window at the current (hidden) url.
  4. Ask the test page's development team to enable the toolbar during accessibility testing.

Why won't ANDI launch on this page?

If after pressing the ANDI favelet button, ANDI does not launch after a few seconds, it could be due to a few things:

  • It could be due to the page telling the browser to enforce a Content Security Policy directive. To determine if this is the issue, open the browser's Developer Tools (F12) and attempt to launch ANDI. If the Dev Tools console shows an error message that says "Refused to load the script...because it violates the following Content Security Policy directive" then this is the issue.

    To use ANDI on this test page, make a request to the page owner to add the ANDI script to the whitelist of approved scripts.

    If the user desires to use ANDI immediately, Content Security Policy (CSP) can be disabled. Note: It is the user's decision to disable CSP and the user's responsibility to re-enable CSP when testing with ANDI has concluded. If users decide not to disable CSP, and ANDI cannot be launched, it is recommended to use other accessibility testing procedures.
    1. Install the Disable Content-Security-Policy extension from the Chrome Web Store
    2. Select the Disable Content-Security-Policy extension button in the Chrome browser toolbar to disable CSP
    3. Navigate to the test page, launch ANDI
    4. When done testing with ANDI, re-enable CSP
    1. In the address bar, enter "about:config"
    2. Under Preference Name, select "security.csp.enable" to disable it
    3. Navigate to the test page, launch ANDI
    4. When done testing with ANDI, re-enable the "security.csp.enable"
    1. Navigate to the test page in Internet Explorer 11, launch ANDI
    2. Internet Explorer does not enforce CSP
  • There could be a JavaScript error occurring. Open the browser's Developer Tools (F12) and attempt to launch ANDI. If the Dev Tools console shows a JavaScript error that relates to ANDI, then send a link to the test page to ANDI's development team by creating an issue on the GitHub page.
  • Your browser or organization could be preventing scripts (such as ANDI) from launching from a favorite/bookmark. To determine if this is the case, try this:
    • Drag and Drop this link: Test Favelet into your browser's favorites/bookmark bar.
    • Activate the favorite/bookmark you just created.
    • If you don't see an alert pop up, then your browser is blocking JavaScript in favorites/bookmarks, in which case you will not be able to use ANDI in this browser.
  • The test page may be very large and have many elements which takes ANDI a longer than normal time to analyze. Try waiting a little longer.

Why can't I inspect this element?

If ANDI has been launched and something is not "inspectable," it could be due to one of these reasons:

  • The content of the page may have changed after ANDI was first launched, and therefore ANDI is not aware of the new content. Try refreshing ANDI.
  • A different module may need to be selected to detect the element.
  • The test page's CSS may be disguising the element. For example, an element may look like a button, but it's not actually a focusable, keyboard accessible button. ANDI (focusable elements) would not recognize this element if it wasn't built using a semantic button tag, or doesn't have tabindex.
  • If mouse hover is not able to inspect an element, try the Next or Previous Element buttons.

Where are the lasers?

ANDI's "lasers" will not work in versions of Internet Explorer prior to 9 (including compatibility modes) because ANDI's "lasers" are built using SVG (scalable vector graphics) which are not supported by older IE versions.

Where is cANDI (color contrast)?

The cANDI module relies upon functionality that is not available in versions of Internet Explorer prior to 9 (including compatibility modes). Testers will need to perform a manual contrast test when cANDI is not available.

Why is ANDI covering up the test page?

Since the ANDI Bar dynamically grows and shrinks depending on the amount of data being displayed for a particular element, mouse hovering can cause the display to overlap with the Test Page.

If ANDI is continually blocking the view of the Test Page, use the next previous element buttons which will always keep ANDI out of the way. You can also try Mini Mode.

If ANDI is still blocking the test page, it is usually due to the responsive design of the test page reacting to the space the ANDI Bar is filling. Try maximizing the browser window, or switching to a larger resolution.

Launching ANDI makes the test page look different

If after launching ANDI, the page looks odd or different, you may have to bear with it for your testing. ANDI has to manipulate some CSS in order allow itself to appear on the page - This can sometimes cause display interference.

If elements become obscured to the point that you can't test the content behind "floating" elements, you may have to engage ANDI's advanced setting, linearize page.

Why is ANDI's Output different from the screen reader's?

Yes, ANDI's Output may occasionally be different from the screen reader's. Here are some reasons why the Output may differ:

  • ANDI uses the DOM to calculate the Output, whereas screen readers rely heavily on the browser's Accessibility API and also inject some of their own phrasings depending on the element type (button, link, etc). Accessibility APIs, especially Internet Explorer's, have many known issues that cause a screen reader's speech to be incomplete or innacurate. This means that even though certain tags and attributes are present on a given element, the API may not inform the screen reader of their presence. Since ANDI is not reliant on the browser's Accessibility API, it may be more accurate technically.
  • Some screen reader software has guessing algorithms to assist its users. For users of assistive technology, guessing is a good thing! Guessing makes up for missing or improper accessibility coding. However, screen readers should not be guessing when explicit accessibility coding is present. Since ANDI is a test tool, it performs no guessing, and its Output is a direct result of any present programmatic associations.
  • ARIA Role attributes may be involved in the HTML structure, which causes screen readers to add additional, intentional verbiage. ANDI's Output is more closely tied to the direct accessible name and accessible description of an element.
  • When humans write complex software (such as screen readers and accessibility test tools), bugs are a fact of life! Let's squash them! If after some analysis you find that ANDI should be providing different Output, please reach out to our development team by creating a github issue.

Contact ANDI's Development Team

I have an idea or issue!

If you have an idea for ANDI or an issue with its behavior, create an issue on the GitHub page. For issues, please provide a link to a page with the issue.