If you do accessibility testing, you’ll want to know about some tricks of the trade– and one of those tricks is using accessibility “bookmarklets.” These are pieces of JavaScript code that you can save as bookmarks on your browser. Then, when you want to test your page, you open one of these bookmarks and it runs the JavaScript code against the page through your browser. And, because it’s just JavaScript, it’s both relatively safe and easy to use on all modern browsers. So grab your favorite browser and choice and read on!
There are two super-useful set of bookmarklets to get. Here are the links plus a short description of each.
Accessibility Bookmarklets (https://accessibility-bookmarklets.org). This is a set of five separate bookmarklets that let you instantly identify landmarks, headings, lists, images, and forms– and get really useful details about each.
Accessible Name and Description Inspector (ANDI)(https://www.ssa.gov/accessibility/andi). This highly-useful tool gives you a lot of technical information about UI elements that is critical to screen reader users and other users of assistive technology. For instance, if you have an element that gets named from several different sources (e.g. alt, aria-labelledby, aria-label, etc), it will tell you exactly what it’s “accessible name” (the text that should be read out by screen readers) together with the sources of that name.
With all these bookmarklets, it’s super-simple to install them. All you do is open your computer’s bookmark bar (in Chrome on MacOS, this is “View | Always Show Bookmarks Bar” or SHIFT-COMMAND-B) and then dragging-and-dropping the bookmarklet onto the bookmark bar.
The installation process is only slightly more complicated if you are using only a keyboard. In that case, both websites have instructions but the basic idea is that you have to manually create a bookmark in your browser using the JavaScript code that comprises the bookmarklet.Then you just go the web page you want to evaluate and press the relevant bookmark. In the screenshot below, I’ve gone to the Converge Accessibility site and pressed on the “Forms” Accessibility Bookmarklet. Selecting this bookmarklet immediately identifies every form element on the page, highlights them with a colorful dark border, and identifies the type of form element. In this screenshot, the bookmarklet has highlighted the input fields for the “sign up for our mailing list” form and identified them as “input” elements.
What Do We Use Accessibility Bookmarklets For?
Accessibility Bookmarklets are amazing! Instead of opening the source code or a screen reader, sometimes it far faster and easier to just pull up a bookmarklet to see if basic accessibility features are available. Here’s some of our favorite ways to use these bookmarklets.
Instantly Spot ARIA Landmarks
Core Concept 1.3.1.2 requires the use of ARIA landmarks and regions on web pages. But, without examining the page using a screen reader, the easiest way by far to instantly spot landmarks and regions is to use the Landmarks bookmarklet. Here is a screenshot of the Converge Accessibility home page showing the effect of applying this bookmarklet. Specifically, it highlighted the menu items at the top of the page as the “navigation” region and the main body of the page as the “main” section. Pretty cool, huh?
Quickly Assess Heading Structure
Core Concept 1.3.1.1 requires that heading elements follow a proper hierarchy. But that means being able to immediately identify headings on a page. The Accessibility Bookmarklets quickly give a sense of the heading structure. Here is a screenshot of the headings bookmarklet applied to the Converge Accessibility home page. In this case, there is an H1 element at the top and another one at the start of the main content. Then, there is a major heading with three H3 subtopics.
It is possible, however, that content may have been changed or moved through CSS– in that case, the Headings Map extension in Chrome may give a more accurate view of the heading structure in the Document Object Model (DOM). That tool, together with a quick code view in the Developer tools, provides a more rigorous view of the heading structure. But, for quickly eyeballing whether heading structure follows the proper hierarchy, there is nothing faster than using the headings bookmarklet.
Find and Check Lists
Sometimes lists can be hard to find. Other times, it’s hard to tell immediately whether a list is one continuous list– or multiple lists that are just cleverly spaced to appear as a single list. Performing a code review is the most accurate approach but a quick way to find lists and see if they form a single list is by using an Accessibility Lists Bookmarklet.
These features are important for accessibility– and WebAlign. Core Concept 1.3.1.5 requires that lists be marked up as lists. Thus, if you have a series of bulleted items on a page that visually appears as a list, it needs to use the <UL> element to structure it as an unordered list. If you want to check that, the lists bookmarklet will tell you immediately.
Here is the Converge Accessibility home page after we have clicked on the Lists Bookmarklet to reveal the list items on the page. First, it shows that the basic navigation items (“Home”, “Products and Services”, “About Us” and “Blog”) comprise an unordered list. And so do the four icons for the social media links in the upper-right corner. Second, it also shows that the menu items under “Products and Services” (i.e. “Litigation Services”, “Expert Accessibility Evaluations”, “WebAlign” and “Other Products and Services”) are themselves an unordered list. Plus, we know that they are continuous lists because only one box marked “UL” appears for each one.
What’s even more cool is Tooltips in each of these bookmarklets provides other useful information. Here for instance, the screenshot shows that the menu has four elements in the list. This is very useful information and further verifies that Core Concept 1.3.1.5 is met because the list of menu items is coded as one continuous list.
Quickly Spot Images (and Non-Images)
Accessibility Bookmarklets also let you spot what is being identified to the screen reader as an image– and, just as importantly, what is NOT being identified to the screen reader as an image. Identifying images– and ensuring that they have proper alternative text– is critical to Core Concept 1.1.1.1. And making sure that decorative images are either invisible or marked with a null alt attribute is the main idea in Core Concept 1.1.1.2.
Again, here is the Converge Accessibility home page after clicking on the Images bookmarklet. As shown in the screenshot, only the Converge Accessibility logo is highlighted. This is because the other icons on the screen are either decorative or support accessibility is a different manner. It this case, these images were specifically
And hovering over the highlighted block reveals that the accessible name that will be read out to screen readers. In this case, that text will read, “Converge Accessibility” to the screen reader. The tooltip also reveals that the image is created using an <IMG> element and that the accessible name comes from an ALT attribute. This is helpful information because an accessible name can be created from several different sources.
Make Sure Forms are Properly Labeled
Lastly, here is what happens when we apply the forms bookmarklet to the Converge Accessibility home page. This time, we’ll combine images to show the tooltip that appears when we hover over one of the input items identified by the bookmarklet. In this case, the bookmarklet not only identified which elements are form elements (highlighted here in dark blue) but it also indicates what kind of form element it is (an input element). Plus the tooltip that appears when hovering over the first name field shows that the words “first name *” (with the asterisk telling the user it is a required field) will be read to the screen reader because that is the accessible name for that element. In addition, the tooltip tells us that the accessible name comes from the aria-labelledby attribute. Pretty cool, huh?
What Do We Use ANDI For?
ANDI is also a very helpful tool but it can be a touch overwhelming because it folds a lot of functionality into a single bookmarklet. You can accomplish a lot of the same tasks as Accessibility Bookmarklets using ANDI, but frankly it’s often faster and easier just to pull up a more limited but focused tool like a specific bookmarklet. ANDI was created by the U.S. Social Security Administration to help their own accessibility testing and it is quite powerful. Here’s some of the ways we’ve found ANDI to be really helpful.
Identify Tab Order Quickly Using ANDI
Want to quickly know how keyboard-only users will interact with the UI controls on your web page? ANDI is really helpful for this. First, open the page you want to test and then click on the “tab order” link in the top of the ANDI toolbar. This will immediately identify the tab order for your web page. Here, I’ve used ANDI on the Converge Accessibility home page and ANDI immediately shows that, in terms of tab order, elements 1-3 are not shown, element 4 is the Converge Accessibility logo, elements 5-16 are the menu items and social media links at the top of the page, and so on.
Immediately Identify Label Elements
ANDI also has the ability to spot <label> elements quickly using a very similar strategy as finding tab order. All you have to do is toggle on the “label tags” link and the details of the label elements immediately pops up. Again, here we’re applied the ANDI toolbar to the Converge Accessibility home page to have all of the label elements highlighted.
Check Color Contrast Quickly
Google Chrome or Microsoft Edge let you check color contrast easily. But, if you have a lot of items on a page to check, a quicker way is often to use ANDI. To do this, go to the page you want to test and click on the ANDI bookmarklet. Then, select the “color contrast” option from the ANDI drop down list. Then, as you hover your mouse over text content, the color contrast will immediately get reported. One neat feature is that ANDI also tells you when a more detailed manual test is required. In the screenshot below, for instance, we were able to see that a manual check is required for the text that appears on the Converge Accessibility home page because it appears against a photograph background.
