Three alternatives if a bookmarklet doesn’t work
published on
When testing for accessibility, bookmarklets are among the tools used. However, sometimes individual bookmarklets don’t work. Here are three alternatives for how a check can be assessed in other ways.
When testing for accessibility, a wide variety of tools are used. In addition to commonly used operating systems, browsers, and screen readers, online services and other programs are part of the toolkit that support testers in their work. This also includes a number of bookmarklets. A bookmarklet helps check a specific aspect of a website, such as the presence of language attributes, the display with increased text spacing, or the existence of the alt attribute for alternative text on images.
Unfortunately, it may happen that existing bookmarklets do not work in certain cases.
The problem
One example is checking lists. For this, there is the Lists Bookmarklet by Paul J. Adams. When I tried to use the bookmarklet in my last test … nothing happened. That was a bit surprising, since this bookmarklet had worked reliably in other testing projects.
A look into the browser console provided clarity. The error message there read: Content Security Policy: The page’s settings blocked the loading of a resource at https://cdn.jsdelivr.net/gh/pauljadam/bookmarklets@master/lists.js (“default-src”).
Some bookmarklets are written in a way that they load additional scripts. In this specific test, however, the script was not loaded for security reasons. The cause is the Content Security Policy (CSP). This setting allows website administrators to restrict the sources from which scripts and other website resources can be loaded to trusted servers. This prevents potentially harmful scripts. As a result, a bookmarklet may work on one site but not on another.
Multiple solutions
So the question is: how do I check the lists? For the test steps applied during testing, there are often several ways to reach the goal.
As a Frontend-Developer, the Browser Developer Tools zu are part of my daily toolkit. A quick document.querySelectorAll('ul, ol, dl') in the web console returns a list of all lists, and this way I can evaluate the test step.
A second option is to search the DOM Markup in the inspector. This works very well with longer search terms such as “blockquote”. Searching for “ul” also returns results, however, far too many, since the term is very short. For lists, this approach is therefore somewhat tedious. Unfortunately, it’s not possible to include HTML-Markup in the search term. Searching for <ul, </ul> or <li> returns no results.
The third option is to use another bookmarklet with the same purpose. An alternative is the Accessibility Testing Bookmarklets by tollwerk, which also include one for testing lists. These bookmarklets explicitly avoid using external scripts and jQuery, so they work without dependencies.
As mentioned at the beginning, bookmarklets are little helpers that simplify the tedious task of searching through source code, making testing more efficient. The solutions described all have their pros and cons. The first two options require some familiarity with the developer tools. Even when this knowledge is available, bookmarklets have the advantage of evaluating a website with a single click - often with graphical highlighting of the results. But if necessary, there are always alternative ways to get the job done.