Using the 1996 text-based Browser 'Links' to optimize website accessibility

In a world driven by flashy visuals and complex user interfaces, accessibility is often overlooked. One unconventional yet effective tool for this is Links, a text-based web browser from 1996. While it may sound archaic, Links provides a unique perspective that can significantly help enhance your website’s accessibility and help you comply with WCAG.

Why use Links for accessibility testing

Text-based browsers like Links simulate how screen readers and other assistive technologies interpret your website. By browsing your site in a text-only format, you can evaluate:

• Content hierarchy and structure: Ensuring logical flow and navigation order.
• Alternative text usage: Confirming images and multimedia have appropriate alt tags.
• Semantic HTML: Checking the proper use of headings, lists, and other structural elements.
• Keyboard navigation: Identifying if all interactive elements are accessible via keyboard.

Setting up Links

1. Install links: On most Linux distributions, or WSL/2 under Windows, use:

sudo apt install links

2. Launch Links:

links https://www.gulla.net

Accessibility Auditing with Links

Here are some practical steps to audit your website’s accessibility using Links:

1. Content Structure and Flow

• Ensure that the navigation and content flow logically.
• Headings (<h1> to <h6>) should follow a hierarchical order.
• Check if screen readers would announce the content in the right sequence.

2. Alt Text Verification

• Navigate through pages and see how Links displays image placeholders.
• Ensure every image is accompanied by meaningful alternative text.

3. Keyboard Navigation

• Test navigation using only the keyboard.
• Use the arrow keys and the Tab key to cycle through links and interactive elements.
• Ensure every element is reachable and logically ordered.

4. Form Accessibility

• Check if all form elements (inputs, labels, buttons) are accessible.
• Confirm that each input has a corresponding label, ensuring users understand the purpose of each field.

Checking my own Optimizely blog

1. The search bar

So what kind of improvements can be done on my own blog? I have this search bar on list pages. It had a placeholder, but no label, and a button with an emoji but no text.

So, how does this look like in 1996?

Not too good! Neither the placeholder nor the emoji on the search button is visible! It's not easy to understand that this is the search bar!

This is what the markup looked like before optimization.

<form method="get">
    <div class="input-group">
        <div class="form-outline ml-auto">
            <input type="search" placeholder="Search blog" id="q" name="q" value="@Model.Query" class="form-control" />
        </div>
        <input type="submit" class="btn btn-secondary" value="🤖" autocomplete="off" title="Semantic AI search, powered by Optimizely Graph blog" />
    </div>
</form>

And after optimization. A label for the search field, and fallback text for the button when the emoji is not shown.

<form method="get">
    <div class="input-group">
        <div class="form-outline ml-auto">
            <label for="q" class="sr-only">Search blog</label>
            <input type="search" placeholder="Search blog" autocomplete="off" id="q" name="q" value="@Model.Query" class="form-control" />
        </div>
        <button type="submit" class="btn btn-secondary ai-search" autocomplete="off" title="Semantic AI search, powered by Optimizely Graph blog"><span class="sr-only">Search</span>🤖</button>
    </div>
</form>

And now the search bar is usable in the text based browser from 1996 too!

2. Tag lists

The same list page has a listing of blog post, and most blog posts has one ore more tags.

So how do the tags look like in 1996? Not good! They are not separated by published date, and nothing indicates that this is tags.

This is what the code looked like before optimization.

@if (listItem.Tags != null)
{
    <span class="tags">
        @foreach (var tag in listItem.Tags)
        {
            <span class="badge badge-secondary">@Html.ContentLink(tag)</span>
        }
    </span>
}

And after the update, a label and changing span for div renders the tag list on a new line.

@if (listItem.Tags != null)
{
    <div class="tags">
        <span class="sr-only">Tags:</span>                    
        @foreach (var tag in listItem.Tags)
        {
            <span class="badge badge-secondary">@Html.ContentLink(tag)</span>
        }
    </div>
}

After the update it's much easier to understand what the tag list is.

So, getting back to basics with a browser from the late 1990s could help improve your website. I made a lot of similar improvements based on my experience browsing my site with a text based browser.

Thanks to attention to detail, this very blog is currently rated number one by webperf of all blogs by Optimizely MVPs.

That's it!