Skip to Content

ANDI

Frequently Asked Questions

Here are some answers to common questions about ANDI.

Definitions

What is Accessible Name?

Accessible Name is the name of an HTML element which will be spoken by screen readers and used by Assistive Technologies. The accessible name is the result of the accessible name computation based on the element's contents, HTML attributes, ARIA attributes, or programmatically associated elements. ANDI, the accessibility testing tool, calculates the accessible name and includes it in the ANDI output.

What is Accessible Description?

Accessible Description is additional text related to an HTML element which will be spoken by screen readers and used by Assistive Technologies. The accessible description is the result of the accessible name computation based on the element's HTML attributes and ARIA attributes. ANDI, the accessibility testing tool, calculates the accessible description and includes it in the ANDI output.

Troubleshooting

Why is my favorites/bookmarks bar hidden?

If the browser toolbar or favorites/bookmarks menu is hidden, try this: Press F10, then select the bookmarks/favorites option to show bookmarks/favorites bar.

If the favorites bar is disabled by the web application...

  1. If using IE, press CTRL + N to open a new window at the current (hidden) url.
  2. If that doesn't work, if using IE, get the current URL and paste into a new window:
    • Right click on the page or press Shift + F10
    • 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. Otherwise, ask the web application's development team to enable the toolbar.

Why won't ANDI work 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. Open Microsoft Edge and go to the Chrome Web Store.
    2. Press the button to "Allow extensions from other stores"
    3. Find the Disable Content-Security-Policy extension from the Chrome Web Store
    4. Select the Disable Content-Security-Policy extension button in the Chrome browser toolbar to disable CSP
    5. Navigate to the test page, launch ANDI
    6. 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 won't ANDI find an element?

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

  • The page content may have changed after ANDI was launched, therefore ANDI is not aware of the changed 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.

Can I use ANDI for mobile accessibility testing?

ANDI does not run on mobile browsers. However, ANDI can be used test accessibility on small screen sizes.

Mobile testing can be simulated in a desktop browser using developer tools (F12) with the Toggle Device Toolbar feature (Ctrl + Shift + M). This feature will adjust the screen resolution to that of a mobile or tablet device. Once this mode is engaged, ANDI can be used to test accessibility on smaller screen sizes.


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

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

  • ANDI, the accessibility testing tool, uses the DOM (Document Object Model) to calculate the Output according to the Accesible Name Computation. Whereas, screen readers rely on more layers than just the DOM. Layers such as the browser's Accessibility API, the accessibility tree, the DOM, their own "tutor text" phrasings.
  • Some screen reader software has guessing algorithms to assist its users. 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 an accessibility testing tool, it doesn't guess. Instead, its Output is a direct result of programmatic associations.
  • When humans write complex software (such as screen readers and accessibility testing tools), bugs happen. Let's squash them! If you are think there is a bug the ANDI Output, please reach out to our development team by creating a github issue.

Why is ANDI covering up the test page?

Since ANDI dynamically adjusts to the data being displayed for a particular element, mouse hovering can sometimes cause ANDI to overlap with the Test Page.

If ANDI is continually blocking the view of the Test Page, use the next previous element buttons which should 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 that ANDI is filling. Try maximizing the browser window, or switching to a larger resolution.


Why is ANDI making 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.


Where is cANDI (ANDI 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.


Where are ANDI's 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.

Other Questions

How do I host my own ANDI?

To host your own copy of ANDI, make a few simple changes in the andi.js file:

  1. Download ANDI's source code from GitHub.
  2. Determine if you are going to host ANDI on a server (https://[ALTERNATE_HOST]/andi/) or locally (file://C:/WS/repos/[ALTERNATE_HOST]/andi/).
  3. In the andi.js file:
    • modify the host_url to point to the location that you decided in step 2.
    • (optional) modify the jqueryDownloadSource location to a custom jquery location.
  4. If you are hosting on a server, upload the modified ANDI source code to the server that you decided in step 2. If you are running locally, skip this step.
  5. Create a new bookmark called "my ANDI" or whatever you choose to name it.
  6. Modify the bookmark's launch script to point to your instance of ANDI:

Contact ANDI's Development Team

Where do I file an ANDI bug?

Uh oh! You found a bug in ANDI? Please create an issue on the GitHub page. Be sure to provide a link to a page with the issue, sample code, or embedded screenshots.

I have an ANDI feature request!

That's wonderful! If you have an idea for how to make ANDI better, please create an issue on the GitHub page and explain away.