Over the years, I have collected quite a few tools for testing website accessibility. They include browser extensions and bookmarklets, tools built into the browser, and tools we have developed ourselves.
Many of the tools I already use can provide information about keyboard focus, heading structure, or language markup. However, I sometimes need to use more than one tool to get the full picture, or the information is presented in a way that does not fit particularly well into my testing workflow.
I wanted a quicker way to bring the details I regularly look for into one place and display them directly on the page I am reviewing.
That is how the three bookmarklets I am sharing today came about:
- Focus Finder
- Heading Map
- Lang Check
These WebAlign® bookmarklets have become some of the tools I reach for most often in my day-to-day work. Since they have made my own testing more efficient, I wanted to make them available so others could use them in their testing as well.
They do not replace the other accessibility tools I use, and they are not intended to. Other tools may provide a different view, additional information, or capabilities that these bookmarklets do not.
What these bookmarklets do is give me quick access to a focused set of information in a format that fits the way I test. That helps me work more efficiently without having to move between several different tools just to answer a particular question.
You can find all three on the WebAlign Accessibility Bookmarklets page.
First, What Is a Bookmarklet?
A bookmarklet looks like a regular browser bookmark, but instead of opening another webpage, it performs an action on the page you are already viewing.
Once you add one to your bookmarks bar or bookmarks menu, you can activate it while reviewing a page. The bookmarklet examines that page and displays the information it finds directly on or alongside the content.
There is no browser extension or separate application to install. Add it once, and it is there when you need it.
Focus Finder
Losing track of keyboard focus is frustrating. It is also something I encounter far too often when testing websites.
A page may have a focus indicator that blends into the background, is partly covered by other content, or is simply difficult to follow through a complicated interface. Sometimes the page does not provide a visible focus indicator at all.
Focus Finder places a clear, high-contrast indicator around the element that currently has keyboard focus. As you press the Tab key and move through the page, the indicator follows along.
You can also change the color of the indicator when one color does not stand out well against the page you are testing.
I use Focus Finder for more than checking whether focus is visible. It also makes it easier to follow the focus order, spot unexpected jumps, notice when an expected control is skipped, and see when focus moves behind or beneath other content.
There are other tools and browser features that can help with these checks. What I like about Focus Finder is that it gives me a consistent way to follow focus directly on the page while I test.
It does not tell me whether the page conforms to WCAG. It makes the behavior easier to observe so I can make that determination
Heading Map
Headings are another area where what we see visually does not always match what is actually in the page.
Text may look like a heading because it is large and bold, but it may not be identified as a heading in the code. The opposite can also happen. Text may be coded as a heading even though it does not serve as one.
Heading Map reads the programmatically defined headings and presents them as an outline. It shows the headings in document order, identifies their levels, and places a marker beside each heading on the page.
This makes it easier to compare the visual organization of the content with the heading structure that a screen reader user may encounter.
Heading Map also calls attention to conditions such as skipped heading levels, empty headings, missing or multiple level-one headings, and certain problems involving headings created with ARIA.
I can find much of this information with other tools. Heading Map simply organizes it in a way that gives me the overview I want while also helping me locate each heading on the page. That combination makes it particularly useful in my own workflow.
Not every condition it identifies is automatically a failure to conform to WCAG. For example, finding more than one level-one heading does not, by itself, tell you whether the page is structured incorrectly. Someone still needs to look at the content and decide whether the headings make sense.
The tool gives you the information. You still have to apply judgment.
Lang Check
Language markup is easy to miss because it usually has no visible effect on the page.
The page should identify its primary language so that screen readers and other assistive technologies know how the content should be interpreted and pronounced. When part of the content changes to another language, that change may also need to be identified.
Lang Check reports the language declared for the page and identifies elements that contain their own language declarations. It highlights those elements and checks whether the declared values appear to follow the expected structure for a language tag.
This can help reveal a missing page language, an empty or malformed value, conflicting language declarations, or places where a change in language has been identified within the content.
As with the other bookmarklets, this is information I can obtain in other ways. Lang Check brings the page language and changes in language together in one view, which makes the review faster and easier for me.
Some results still require a person to interpret them. Lang Check can tell you that a language value appears structurally valid. It cannot reliably tell you whether the words inside that element are actually written in that language.
Accessibility Was Part of the Design
Accessibility testing tools should not unnecessarily exclude accessibility testers with disabilities.
For that reason, I deliberately designed the bookmarklets so their interfaces can be operated with a keyboard and used with a screen reader. The controls have programmatic names and clear focus indicators, status information is not communicated by color alone, and the interfaces are designed so that important changes and results are available to assistive technology.
Some features still have a visual component, such as the indicators and highlights placed directly on the page. However, the results panels provide keyboard and screen reader users with access to much of the information the bookmarklets collect.
This was important to me because many blind people and people with other disabilities work as accessibility testers. They should be able to use the tools involved in that work whenever the information and functionality can reasonably be made accessible.
Built Around the Way I Test
There is no shortage of accessibility testing tools, and many of them are very good at what they do. I still use a number of them regularly.
These bookmarklets were not created because those tools were inadequate. They were created because I wanted certain information presented together, directly on the page, and in a way that better supported how I move through an accessibility review.
That is also why each bookmarklet is intentionally focused. None of them scans an entire website, evaluates every applicable WCAG requirement, or determines whether a page conforms to WCAG.
They help me get to the information more quickly. I still need to understand what the information means, decide whether there is an accessibility issue, and use other tools or testing methods when a different view is needed.
That balance is what has made these bookmarklets useful in my own work.
Try Them on a Page You Are Testing
Focus Finder, Heading Map, and Lang Check are available from the WebAlign Accessibility Bookmarklets page.
Each tool includes installation and usage instructions, more information about what it checks, known limitations, and a way to report a problem or suggest an improvement. There is also a keyboard-only installation guide for people who cannot or prefer not to drag a bookmarklet onto the bookmarks bar.
Because a bookmarklet is saved directly in your browser, an installed copy will not update automatically when we release a new version. To receive notices when the bookmarklets are updated, you can sign up for the Converge Accessibility mailing list and install the latest version when it becomes available.
The best way to understand how these bookmarklets work is to try one on a page you are already reviewing and see whether it fits the way you work.
Explore the WebAlign Accessibility Bookmarklets
Need Help with a Broader Accessibility Effort?
Bookmarklets can make parts of accessibility testing easier, but they are only one piece of the process. If your organization could use help with accessibility testing, remediation guidance, or a broader accessibility strategy, contact Converge Accessibility.
Want to See More Content Like This?
Want the latest blog posts, videos, white papers, and announcements? Sign up for our mailing list and stay in the loop!
We're Here to Help When You're Ready
Take a deep breath. Then feel free to reach out to our team when you're ready to discuss your accessibility needs.
0 comments on “Why I Built Three New Accessibility Bookmarklets”