Favorites/Bookmarks Bar Has Been Disabled
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:
- Press F10
- 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
- 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.
- 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
- 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)?
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.