Blog posts - jamesjacobs.me

Setting up Windows Screen Readers on a Mac

2026-03-28T00:00:00Z

I recently picked up a Mac mini for personal projects and went through the usual process of setting up my development and testing tools. Like most accessibility specialists, I regularly work with multiple screen readers. Macs come with VoiceOver built in, but getting JAWS and NVDA running on a Mac takes a few extra steps.

Why test in multiple screen readers

When testing, experimenting, and building UI components for the web, I test in JAWS, NVDA, macOS VoiceOver and iOS VoiceOver, unless it's something tried and tested, in which case I'll give it a quick pass with VoiceOver.

The latest WebAIM survey shows the top 3 most commonly used screen readers are:

NVDA (NonVisual Desktop Access). Windows-only. Free
JAWS (Job Access With Speech). Windows-only. Paid
VoiceOver. Included with macOS and iOS.

While the basic experience is similar, each screen reader announces things slightly differently, has different browser and ARIA support, and like any software, can have bugs and quirks. Testing in multiple screen readers helps build up a more complete picture of the screen reader experience. Sometimes, with more complex UI components, you can encounter issues specific to a certain screen reader.

Setting up a Windows Virtual Machine

Since neither JAWS nor NVDA supports macOS, we need to set up a Windows virtual machine. In the past, I've used VirtualBox, but since moving to an Apple Silicon Mac, I've found that UTM performs better and has been easier to work with. I had performance issues running Windows in VirtualBox, which meant the audio would cut out, not great when you’re relying on speech output.

Download Windows 11

First, we need to grab Windows 11. I prefer to use CrystalFetch (opens App Store), a free macOS app that makes legally downloading the latest Windows builds really easy.

Open CrystalFetch and:

Select Windows 11.
Select latest under build.
Click Download.

Alternatively, you can download directly from Microsoft.

Buy a Windows 11 licence key

I bought a licence key from Product Codes. At the time of writing, a Windows 11 Pro licence key was £9.90.

Set up UTM and install Windows

Download and install UTM.

Once installed:

Click "+ Create a New Virtual Machine".
Click Virtualize.
Click Windows.
Select the memory and CPU cores you'd like to use. I used the minimum spec for Windows 11 Pro - 4GB of memory and 2 CPU cores.
Select the ISO we downloaded with Crystal Fetch, then tick "Install Windows 10 or higher" and "Install drivers and SPICE tools" checkboxes.
Enter the size of the virtual hard drive for the VM. I went with the minimum required 64GB.
Click save and let UTM finish setting up the VM.
When the VM launches, press any key to start the Windows installer when you see the "press any key to boot from disk".

You should then be taken through the Windows installer, where you can enter the product key you bought earlier.

Once Windows has finished installing, updating and restarting, we can start downloading our browsers and screen readers.

If you hit any issues, check out the Windows set up guide on the UTM site.

Install NVDA

Download NVDA within the newly created VM. Although it's free, I'd recommend making a donation to support the software and future development.

Once installed, there are two settings worth enabling.

Visual Highlight

This makes it easy to see the element NVDA is currently focused on and announcing as you navigate through the page. It’s slightly different from standard focus indicators provided by the site/browser, as it will also be shown on any non-interactive element, such as text that’s being read out.

Start NVDA.
Right-click the NVDA icon in the system tray.
Click Preferences, then Settings.
Within the Settings dialog, click Vision.
Click Enable Highlighting, under Visual Highlight.

Speech Viewer

Speech viewer displays a text log of the NVDA spoken output. It's useful, but bear in mind that the speech viewer doesn't always match exactly what NVDA has spoken, so it shouldn't be used as a replacement for listening to the spoken output.

Start NVDA.
Right-click the NVDA icon in the system tray.
Click Tools, then Speech Viewer.
The Speech Viewer will then open.

Install JAWS

Download JAWS within the VM.

JAWS is a paid product, with prices ranging from the hundreds to the thousands, depending on the licence. It does, however, offer a 40 minute demo mode for evaluation. Keep in mind that the End User License Agreement prohibits using the 40-minute demo mode for accessibility testing.

Like NVDA, JAWS also contains a couple of useful features worth knowing about.

Speech History

Similar to NVDA Speech Viewer, JAWS contains a Speech History feature that shows the last 500 lines of speech. You can open the Speech History dialog by pressing Insert + Spacebar + H.

Highlight Virtual PC Cursor

JAWS also contains a visual highlight for tracking the position of the JAWS cursor. In JAWS 2026 it's enabled by default. You can find the setting and related options for changing the appearance of the highlight by:

From the JAWS dialog, click Utilities, then Settings Center.
In the settings center, in the left-hand tree view, click Visual Tracking.
Enable "Highlight Virtual PC Cursor". You can modify the appearance of the highlight here too.

Configure the keyboard

By default, both JAWS and NVDA use the Insert key for certain commands, which isn't present on Apple keyboards. There's a couple of options to work around this.

Option 1: external PC keyboard

The easiest option is to plug in a full sized PC keyboard, though if you're working from a laptop and move around a lot, it's not ideal.

Option 2: remap insert key

There are a number of apps that let you remap keys. Not all will work with UTM due to how it receives keyboard input from the host machine. Mac apps like Karabiner-Elements, though often recommended, will not work with UTM. After trying tools like PowerToys and AutoHotKey, I found SharpKeys, which is free and straightforward to set up.

Within the VM:

Download and open SharpKeys.
Click Add, then under "Map this key", select the key you want to trigger Insert (make sure you pick a rarely used key).
Then, under "To this key", select Insert and map it to the Insert key.
Click Write to Registry.
Restart the VM.
You can now use your chosen key as Insert .

Avoid using Caps Lock

Both JAWS and NVDA have the option to use Caps Lock as a modifier key in addition to Insert. I'd avoid that, as caps lock behaves slightly differently on Apple keyboards and may not pass through to the VM as expected.

Selecting the keyboard layout

Both JAWS and NVDA use slightly different keyboard commands depending on whether you're using a desktop or laptop keyboard. Make sure you have the appropriate keyboard layout selected. For most Apple keyboards you want to use Laptop.

JAWS keyboard layout

Start JAWS.
Click Options, Basics.
Under Use Keyboard Layout, select Laptop.
Click OK to save.

NVDA keyboard layout

Start NVDA.
Right-click the NVDA icon in the system tray.
Click Preferences, then Settings.
Under keyboard, change Keyboard layout to Laptop.

Using Function (F) keys

Certain NVDA and JAWS commands require the use of a function key. Because Apple keyboards use function keys for things like screen brightness, you'll need to press fn + the relevant function key to trigger the command in the VM.

So for NVDA commands like Insert + F7, you'll need to press Insert + fn + F7 on your Apple keyboard.

Alternatively, you can set F keys to function as standard function keys in macOS settings, which will pass through to your VM

Screen readers work better when paired with a supported browser. While screen reader support for different browsers has improved over the past few years, I'd recommend the following pairings when testing:

JAWS + Chrome or Edge.
NVDA + Chrome or Firefox.
VoiceOver + Safari.

These also match the most common screen reader browser pairings from the latest WebAIM Screen Reader Survey.

Set up complete

Once everything is set up, switching between macOS VoiceOver and Windows screen readers is just a case of firing up your new VM. You can now cover most real-world combinations without leaving your Mac.

Useful links

Deep dive: crafting accessible links

2026-03-17T00:00:00Z

The humble link. A small but mighty, fundamental piece of HTML that's arguably the backbone of the entire web. Links are everywhere, and we use them thousands of times a day, but what goes into making a link truly accessible? In this post, I'm going to deep drive into link accessibility, covering the basics, things to avoid, and some common problematic patterns.

So grab a drink, some snacks, and strap in.

Foundations

Accessible names and roles

You’ll see the terms "accessible role" and "accessible name" used throughout this post. They describe what assistive technology, such as screen readers, exposes to users.

The role tells assistive tech what something is and how it behaves. Native HTML elements come with built-in roles. For example, an <a> with a href has the role of “link”. Generic container elements like <div> and <span> carry no semantic meaning.
Roles can be explicitly set with the role attribute. This is generally only necessary when not using native HTML or in rare cases where the default needs to be changed.
The accessible name is the label announced alongside the role. For links, this is usually the text inside the <a></a> tags.

If you want to dig deeper, see the MDN pages on WAI-ARIA roles and accessible names.

Use semantic markup

Let's start with the basics: when is a link actually a link?

If an anchor tag <a> has a href, it's a hyperlink:

<a href="https://www.jamesjacobs.me">James Jacobs</a>

Native elements have semantic meaning and behaviour built in. Taking the example above:

It's keyboard accessible. You can Tab to it and activate with Enter.
It looks like a link (blue with an underline) in all common browsers.
It's announced as a link by screen readers.
It navigates somewhere when activated.

A link is not just something that looks clickable. It’s a specific element with built-in meaning and behaviour. However, not all links are created (or coded) equally...

If you are involved with accessibility testing, you’ve probably seen something like this:

<a id="some-id-for-js">Link text</a>

Can you spot the difference? There's no href.

Sometimes, developers omit the href attribute and use JavaScript to handle navigation. The problem is that, according to the HTML living standard, an <a> element without an href is just a placeholder for where a link might have been placed.

If the a element has no href attribute, then the element represents a placeholder for where a link might otherwise have been placed, if it had been relevant, consisting of just the element's contents.

Without a href, an <a> element does not have the role "link". It falls back to role "generic". It won’t be announced as a link by screen readers and won’t appear in lists of links. Semantically, it’s not much different from a <span>.

Another common inaccessible pattern is along the lines of:

<div tabindex="0">Link text</div>

In both cases, the developer has to recreate the behaviour and semantics that a native link would have provided, by adding:

JavaScript to handle navigation and activation.
tabindex="0" to make it keyboard focusable, as a <div>, or a <a> without a href, can't be tabbed to via the keyboard.
role="link" so assistive technology recognises it as a link.
Custom styling to make it look like a link.

There are other shortcomings, too. For example, the CSS :link pseudo-class won't apply styles to <a> tags without a href.

Semantic HTML provides a lot of out of the box functionaility, so use it wherever possible.

Links vs buttons

All too often, links and buttons are used interchangeably. This creates a number of issues. Simply put: links go places and buttons do things.

If it navigates somewhere, on the page or to a different page, use a <a> with the relevant href.
If it triggers an action, such as opening a menu, revealing content, submitting a form, or opening a modal, use a <button>.

Why is this important? Native HTML elements have semantic meaning and set expectations on how they will behave when encountered and interacted with. When someone activates a link, they expect navigation. When they activate a button, they expect an action.

Screen reader users hearing a link announced will expect to go somewhere if they activate it.
Screen readers can list elements of a certain type on the page, including links - so users expect things that behave like a link to be listed there.
Keyboard users expect to be able to tab to interactive elements, like links and buttons, and activate a link with Enter and a button with Space or Enter.

When the wrong element is used, those expectations may not be met. For example, when developers do things like:

<a href="#" role="button" id="id-for-javascript">View Details</a>

That element is programmatically presented as a button (imagine it's visually presented as one too). A screen reader will announce it as a button, due to the role. A user might reasonably press Space to activate it. But unless additional JavaScript has been added to handle the Space key, nothing happens. The element looks like a button, sounds like a button, but does not behave like one - that's confusing.

Use the right element for the job. Native elements already include the correct semantics, keyboard behaviour, and assistive technology support.

Writing accessible link text

Make the destination clear

Link text should make it clear where the link leads.

Links are not always read in context. Screen reader users can pull up a list of links on a page and move through them one by one. Being presented with a list of "click here" or "read more" provides no useful information to go on.

When reviewing or writing links, try reading them on their own. If the surrounding paragraph disappeared, would the destination still be obvious?

Don't: use ambiguous link text

Click here to learn how to test with screen readers.

Do: make it clear where the link leads

Learn more about how to test with screen readers.

A recommended approach is to use the target page's <title> text as the link text, assuming the title is descriptive. In the example above, the target page has a page <title> that starts with "How to test with a screen reader", therefore, the same is used for the link text.

While WCAG 2.4.4 Link Purpose (In Context) (Level A) allows for link context to be provided by text in the same paragraph, list item, table cell or header, this doesn't help screen reader users navigating from link to link or when reviewing a list of links out of context.

Keep link text concise

Avoid linking whole sentences or large blocks of text. Long links can be difficult and time-consuming to listen to in a screen reader and potentially awkward to activate with speech recognition software.

Instead, link just enough words to make the destination clear.

Don't: link unnecessary words

<p>
  <a href="/training-videos">
    You can find out more about accessibility 
    by watching our free accessibility training videos
  </a>
</p>

Do: link enough to preserve meaning

<p>
  You can find out more about accessibility 
  by watching our 
  <a href="/training-videos">
    free accessibility training videos
  </a>
</p>

Use consistent wording

If multiple links point to the same page, use the same link text.

WCAG 3.2.4 Consistent Identification (Level AA), requires components that have the same function, within a set of pages, to be identified consistently. It's a good idea to use the same link text for the same destination, even on links in a single page.

Consistency reduces cognitive load. It helps people build a mental model of your interface and move through it with confidence.

Don't: use different link text for the same destination

<!-- Page 1 -->
<a href="/contact">Contact us</a>
<!-- Page 2 -->
<a href="/contact">Get in touch</a>

Do: be consistent with link text

<!-- Page 1 -->
<a href="/contact">Contact us</a>
<!-- Page 2 -->
<a href="/contact">Contact us</a>

Include the file type and size in the link text

When linking to non-HTML documents, let the user know the type and the size of file they are opening.

Do: inform the user of the file type and size

<a href="sales-figures-jan-2026.pdf">
  Sales figures Jan 2026 (PDF, 2MB)
</a>

Avoid using raw URLs as link text

Linked URLs are:

Hard to read at a glance: long strings of slashes, numbers, and tracking parameters are difficult to read, scan and understand
Unclear and sometimes suspicious: A shortened link gives no indication of where it leads. For example, where does https://tinyurl.com/yetpupyz actually go?
Difficult to follow with screen readers: which read them character by character, e.g., "H T T P S colon slash slash W W W dot james jacobs dot me slash guides slash how dash to dash test dash with dash a dash screen dash reader"

Don't: link RAW URLs

<a href="https://tinyurl.com/yetpupyz">
  https://tinyurl.com/yetpupyz
</a>

Do: use clear descriptive link text

<a href="https://tinyurl.com/yetpupyz">
  How to test with screen readers
</a>

Though linked URLs are not necessarily a WCAG failure under 2.4.4 Link Purpose (In Context)(Level A) or 2.4.9 Link Purpose (Link Only)(Level AAA), if they are human-readable, it's rarely the clearest option.

Clear, descriptive link text reassures people about where the link leads and why it is there.

Non-text links

When icons, images, and other non-textual elements are linked, there are extra considerations to ensure the link remains accessible.

Icon links with visible text

Icons included within a link, in addition to visible link text, are typically decorative. In these cases, the icon should be hidden from assistive technology to avoid unnecessary noise. How the icon is added will determine how best to hide it.

Inline images using <img> can use an empty alt attribute to tell assistive technology to ignore the image:

<a href="...">
  <img src="facebook-icon.png" alt /> 
  Facebook
</a>

Many icon font libraries, like Font-Awesome, use CSS pseudo-elements to display the icon. Typically, these are ignored by assistive technology, but to be safe, you can add aria-hidden="true" to the element providing the icon. This prevents some screen readers, like VoiceOver, from displaying the icon as a question mark in a rectangle (⍰), which could be confusing to sighted screen reader users.

<a href="...">
  <span class="fa-brands fa-facebook" aria-hidden="true"></span>
  Facebook
</a>

In the example above, the visible text provides the accessible name. The icon is purely decorative.

Icon links without visible text

Sometimes an icon is the only visible content inside a link. Social media links in footers are a common example. These links can be harder for speech recognition software users to activate, as it's not obvious what they should say to activate the link. Typically, someone using speech recognition software will say "click", followed by the visible text label. In the case of icon only links, there is no visible text label, so they have to use additional steps to activate the link. For this reason, it's worth avoiding icon-only links.

If they are used, you must provide an accessible name for the icon link.

One approach is to include visually hidden text inside the link:

<a href="...">
  <span class="fa-brands fa-facebook" aria-hidden="true"></span>
  <span class="visually-hidden">Facebook</span>
</a>

The hidden text becomes the link’s accessible name and what's announced by screen readers.

Make sure the text is hidden visually but not from assistive technology. Do not use display: none or visibility: hidden, as these hide content from assistive technology.

The common visually hidden pattern uses the "clip method" and typically looks like:

.visually-hidden {
    clip: rect(0 0 0 0);
    clip-path: inset(50%);
    height: 1px;
    overflow: hidden;
    position: absolute;
    white-space: nowrap;
    width: 1px;
}

The Vispero team did a great job of breaking this down in their post the anatony of visually-hidden.

Avoid using aria-label on the link, as Adrian Roselli notes - there are concerns around aria labels and translations.

Linked images

When an image is the only content inside a link, its alt text becomes the link’s accessible name and must be provided. It does the job that visible link text would normally do. Because of that, don’t describe what the image looks like. Use the alt text to describe the link’s destination or purpose.

The alt text is also shown if the image fails to load, so it needs to make sense as visible link text. For example:

The same principles apply as with any other link. Write a clear, specific label that explains the destination of the link.

If a linked image has no alt text, the screen reader experience is poor. Some screen readers will just announce "link". Others may attempt to read the file name or URL. Neither is helpful.

Don't: describe the image in the alt text

<a href="...">
  <img src="passport.png" alt="A blue british passport">
</a>

Example screen reader output: "link, image, a blue British passport".

Do: use alt text to label the link

<a href="...">
  <img src="passport.png" alt="Apply for a passport">
</a>

Example screen reader output: "link, image, apply for a passport".

Link behaviour

Avoid opening links in new tabs (warn users if you do)

Opening a link in a new tab can be disorientating for some users as it changes browsing context without warning. In most cases, leave the control with the user and let them decide whether to open the link in a new tab.

There are some situations where it may add value, for example:

The link opens context-sensitive help that supports the current task.
The user is working in a secure or form-based flow, and navigating away would risk losing data.

If there is a clear reason to open a new tab, warn the user in the link text.

Don't: open links in new tabs unnecessarily

<a href="https://www.facebook.com" target="_blank">
  Follow us on Facebook
</a>

Do: warn users when a link needs to open in a new tab

<a href="https://www.somewebpage.com/help" target="_blank">
  View detailed instructions (opens in new tab)
</a>

If you have a group of links that all open in new tabs, you can reduce repetition by:

Adding a short note before the group, such as “The following links open in a new tab”, and
Including visually hidden warning text inside each link for screen reader users.

WCAG techniques G200: Opening new windows and tabs from a link only when necessary and G201: Giving users advanced warning when opening a new window cover this pattern: only open new windows when necessary, and provide advance warning.

It’s also worth remembering that target="_blank" has security and privacy implications. If you use it, make sure it’s implemented safely.

Disabling links

In almost all cases, it's best to avoid disabling links.

It's an unusual, rarely seen pattern. HTML does not support the disabled attribute on <a>. Users expect links to be interactive. Disabling a link will likely lead to confusion. In cases where you think there is a need to disable a link, it's arguably better to remove the link completely or display it as plain text.

If, for some reason, you must disable a link (ignoring that it's probably a bad idea), then you need to make sure the disabled state is visually conveyed to the user and programatically conveyed to assistive technologies. Depending on the use case, it may be beneficial to explain why the link is disabled.

Remember at the start of this post, I mentioned that a link without a href is a placeholder link? That is essentially what we need, but with some added ARIA.

<a role="link" aria-disabled="true">Disabled link</a>

This approach:

Removes the href, so the link can't be focused or activated.
Explicitly sets the "link" role, as without the href its role changes from "link" to "generic" and is therefore not announced as a link to screen readers.
Conveys the disabled state to assistive technologies via aria-disabled="true"

Without an href, the element will not be keyboard focusable, but it can still be discovered by screen readers. That behaviour is consistent with other disabled elements, such as buttons and form inputs.

Scott O'Hara does a great job of going into more detail on this approach in disabling a link.

Styling considerations

Visually differentiate text links

It should be obvious when text is a link, either through its position, such as in a navigation menu, or through its visual styling.

By default, links are blue and underlined. Many sites change this to match their branding or design ideals, which is fine. The problems start when links are styled to look like normal body text, or when colour alone is used to distinguish them, especially when they're surrounded by plain text.

Not everyone can reliably perceive colour differences. People with low vision or colour vision deficiency may struggle to spot a link if colour is the only visual cue, especially when it sits within a paragraph of text.

Don't: rely on colour alone

I've written a guide on how to test with a screen reader, which goes into more detail.

Do: use a secondary visual cue

I've written a guide on how to test with a screen reader, which goes into more detail.

To make links easy to recognise, use an additional, consistent, visual cue to distinguish them from plain text. An underline is the most common and widely understood option, though other approaches work if they are consistent and clearly distinguish links from surrounding text.

While a link using colour alone to differentiate itself from plain text may not fail WCAG 1.4.1 Use of Color (Level A) if it contrasts with plain text by at least a 3:1 ratio, or even uses the same colour as the surrounding plain text, using colour alone to differentiate links should be avoided.

Text contrast rules apply

As with unlinked text, text contrast ratio requirements still apply. Aim for a 7:1 or greater contrast ratio where possible, which meets the requirements of WCAG 1.4.6 Contrast (Enhanced) (Level AAA), or at minimum, a 4.5:1 as required by WCAG 1.4.3 Contrast (Minimum) (Level AA).

Use a highly visible focus indicator

Focus indicators are critical for keyboard users. They highlight which element currently has keyboard focus and will therefore receive keyboard input. By default, browsers display some form of focus indicator, often a blue outline. While these have got better in recent years, they can still be hard to see in certain situations.

Crafting your own, highly visible focus indicator is strongly recommended. If you tab through this site, you'll see that I use a 3px solid outline and a yellow background colour when elements are focused, which contrasts on both light and dark backgrounds, and also meets the requirements of WCAG 2.4.13 Focus Appearance (Level AAA).

Don't: disable focus indicators

:focus, 
:focus-visible { outline: none; }

By disabling focus indicators, the user is left guessing as to which element has keyboard focus and will receive keyboard input.

Do: use a highly visible focus indicator

There are many ways to create great looking, accessible focus indicators - Sara Soueidan does a great job of exploring this further in a guide to designing accessible, WCAG-conformant focus indicators.

Related WCAG success criteria:

1.4.11 Non-text Contrast (Level AA): details contrast requirements for focus indicators
2.4.7 Focus Visible (Level AA): requires a visible focus indicator to be present
2.4.13 Focus Appearance (Level AAA): contains enhanced requirements around sizing and contrast
2.4.11 Focus Not Obscured (Minimum) (Level AA): requires focused elements to be at least partially visible
2.4.12 Focus Not Obscured (Enhanced) (Level AAA): require focused elements to be fully visible

Make links large enough to comfortably activate

Not everyone uses a mouse with steady hands at a desk. Some people use a small phone with one hand. Some use a trackpad that is less precise. Others live with tremors, arthritis, or reduced motor control. Even a temporary injury or bumpy bus journey can make small targets hard to hit. If links are too small or packed tightly together, activating the right one can be difficult.

Ideal size: Apart from links in sentences, aim for the target area of links to be at least 44px by 44px - which meets 2.5.5 Target Size (Enhanced) (Level AAA)
Minimum size: If 44px by 44px sizing isn't possible, ensure a minimum of 24px by 24px - required by 2.5.8 Target Size (Minimum) (Level AA)
Spacing: Leave enough space between nearby links to prevent accidentally activating the wrong link

While 2.5.8 Target Size (Minimum) (Level AA) does allow for smaller target sizes if they are adequately spaced, larger controls are easier to reliably activate.

Hover styles

Style: It's a good idea to add styling that visually differentiates when a link is being hovered over. This could be increasing the width of the link underline, changing the background, or other visuals.
Cursor: By default, browsers change the cursor pointer to a hand icon when hovering over a link. That's something users are familiar with, so I'd recommend against overriding it.

The link hover styles on this site increase the underline and keep the default link cursor:

Common patterns to avoid

These patterns introduce barriers for many different users, including those who use screen readers and speech recognition software.

Avoid pairing a heading with a generic link

A common pattern often seen on blog post list pages places a heading above some short text, followed by a link such as "Read more". For example:

<h2>Super cool blog post</h2>
<p>Some content</p>
<a href="/supercool-blog-post">Read more</a>

As mentioned above, link text should always describe the destination. Instead of rewording the link, we could remove it and link the heading text:

<h2><a href="/supercool-blog-post">Super cool blog post</a></h2>
<p>Some content</p>

This keeps the link text clear and avoids repeating information that already appears on the page.

Avoid linking an image and nearby text to the same place

Similar to the last pattern, listing pages often show an image next to a heading, with both linking to the same page. This results in two separate links that take the user to the same destination, two tab stops, and screen reader users hearing the link twice in close succession.

<a href="/making-links-accessible">
  <img src="links.png" alt="Making links accessible">
</a>
<h2>
  <a href="/making-links-accessible">Making links accessible</a>
</h2>
<p>Some content</p>

A simpler approach is to link the heading and unlink the image, adding alt text as appropriate (or leaving it empty to mark the image as decorative depending on the situation).

<img src="links.png" alt="Screenshot of links with poor link text">
<h2>
  <a href="/making-links-accessible">Making links accessible</a>
</h2>
<p>Some content</p>

Don't use the same link text for different destinations

Good link text informs the user where the link will lead. When the same link text is used for different destinations, things become confusing and uncertain. For example:

<h1>Available courses</h1>
<h2>Art</h2>
<p>...</p>
<a href="/art">Explore courses</a>
<h2>Business</h2>
<p>...</p>
<a href="/business">Explore courses</a>

Screen reader users reading these links out of context may assume that they all lead to the same "explore courses" page, when they don't.

There are various approaches that could be taken here, depending on the content, such as supplementing the link with visually hidden text, linking and rewording the headings, or just improving the link text:

<h1>Available courses</h1>
<h2>Art</h2>
<p>...</p>
<a href="/art">Art courses</a>
<h2>Business</h2>
<p>...</p>
<a href="/business">Business courses</a>

Conclusion

If you made it this far, thank you! I appreciate that this is a long post. I did consider splitting it into a series of smaller posts, but keeping everything on one page felt more useful in this case.

Inaccessible links are still a common problem on the web. The 2025 WebAim Million report found that 13.7% of the top one million most popular homepages contained link-related accessibility issues.

Using semantic links and descriptive link text is a relatively easy way of making your web sites and applications more accessible. Much of the information in this post can also be applied to other mediums too - documents, emails, and social media.

The accessibility pitfalls of truncating text

2025-11-24T00:00:00Z

Truncated text, where text is cut off with an ellipsis or fades away, is still something often seen on the web, especially within web applications. Usually as a way to prevent long text from wrapping or for visual consistancy. When text is truncated it can hide meaning, effect understanding and place extra effort on people who already face barriers when using the web.

In this post, I’ll look at why text is truncated, how it is usually done, the accessibility issues it causes, and what to do instead.

Why text is truncated

Designers and developers typically truncate text to:

Preserve visual balance: even when it limits what users can read
Control content of unknown length: such as content entered by users in a CMS or pulled from external systems
Maintain fixed datatable layouts: where rows, columns, and cells stay a uniform size
Optimising for different devices: by reducing visible text on smaller screens

How is text truncated

CSS (most common method)

Truncating text is typically done by CSS. Many design systems such as Bootstrap and Tailwind include classes that truncate text. Text truncated in CSS is typically done by setting a width or max-width on the element or container plus:

.truncate {
  overflow: hidden;
  text-overflow: ellipsis;
  white-space: nowrap;
}

Text can also be truncated after a set number of lines:

.multi-line-truncation {
  display: -webkit-box;
  -webkit-line-clamp: 3;
  -webkit-box-orient: vertical;
  overflow: hidden;
  max-width: 230px;
}

Because CSS truncation is purely visual, the full text still exists in the page. This becomes important later when looking at screen reader support.

JavaScript or server side truncation

Text truncation can also be handled with JavaScript or server side logic, where strings are cut short when they reach a certain length and ellipses appended, or worse text is truncated in the middle of the string - for example: "This text is [...] and ends here".

This approach should be avoided. It permanently removes content, meaning screen readers and other tools cannot access the full text. It also increases the risk of cutting words or sentences in confusing ways.

Who is affected

Truncated text can affect everyone, especially when meaning or context is lost. Some groups face extra barriers:

People with vision impairments: who use higher levels of zoom, use larger font sizes or modify text through custom styles
People with mobility impairments: who use voice control software to interact with content
People with cognitive impairments: who benefit from seeing complete information
People with language difficulties: who may need full words and sentences to read comfortably
Keyboard-only or touch users: Sometimes, developers hide truncated text behind a hover event on the truncated text, which wouldn't be accessible to keyboards or people using touch devices
Smaller screens: where truncation is triggered by responsive layouts or zoom

Issues caused by text truncation

Here is a simple CodePen with examples of single line truncation, multi line truncation, and a truncated button. The truncation is intentionally strong to make the issues easier to see.

See the Pen Truncating text by James Jacobs (@jamesjacobs) on CodePen.

Effects on text style modification

Many people change how text looks on their device. Some do this by choice, others out of need. These changes may be set in the browser, the operating system, or through third party tools.

Common changes include:

Larger font size
Increased line height
More space between paragraphs, words or letters

Increased font size

In the screenshot below, taking the CodePen example, I've increased the default text size in my browser to extra large. Due to the text size increase, more of the text is cut off, futher reducing readability and meaning.

Increased text spacing

Using the 1.4.12 Text Spacing bookmarklet (credit to Steve Faulkner) to apply increased line height, paragraph, letter and word spacing that WCAG 1.4.12 Text Spacing (Level AA) requires support of, we can see a similar effect with additional text being cut off.

Increased font size and text spacing

Combining both an increased font size and increased text spacing makes matters even worse to the point where meaning is completely lost.

Browser zoom

Some sites apply truncation only at smaller screen widths using media queries. Browser zoom effectively reduces the viewport width, which can trigger the same truncation.

This means users who zoom in may lose content even on large screens.

Here's an example of truncation applied via CSS media queries targetting smaller screen widths (also triggered by higher levels of browser zoom on larger screens):

Effects on screen readers

At the time of testing, JAWS, NVDA and macOS VoiceOver read the full untruncated text without any effect. This is because the CSS method for truncating text is a purely visual effect, the text is still in the DOM and not hidden from the accessibility tree.

Effects on voice control and speech recognition

Speech recognition and voice control software, such as Dragon, allows people to browse the web and interact with controls using spoken commands. These tools rely heavily on visible text labels. For example, saying "click save" activates a button with the visible text "Save".

When text is truncated, visible labels become shorter or unclear. This makes controls harder or impossible to activate by voice and forces users to rely on slower workarounds.

The impact depends on how much the text is truncated. Using the button in the CodePen as an example:

The full button text (and accessible name) is "Apply for a new passport"
When truncated to "Apply f...", the button can still be activated by saying "click apply", though additional steps will be required if multiple "apply" buttons exist
When further truncated to "App...", saying "click app" no longer works

Once visible text is reduced to partial or indistinguishable words, users must switch to alternative interaction methods. One common workaround is the mousegrid, which overlays a numbered grid on the page and requires users to narrow down the target area step by step before activating the control.

In the CodePen example, activating the button this way takes five separate steps before the user can say "mouse click". This adds significant time, effort, and frustration compared to using clear, untruncated labels.

Mousegrid step 1

Mousegrid step 2

Mousegrid step 3

Mousegrid step 4

Mousegrid step 5

WCAG considerations

Depending on the situation and how truncation is used, it may lead to failures of several WCAG success criteria:

1.3.1 Info and Relationships (A): potentially a failure as the truncation is only visually and not programatically conveyed
1.4.4 Resize Text (AA): if text cannot be resized up to 200% without loss of content (see F69)
1.4.10 Reflow (AA): if truncation occurs as a result of reflow at smaller viewport widths, such as 320 CSS pixels wide or 1280px with 400% zoom, and no alternative way to access the full content is provided
1.4.12 Text Spacing (AA): if support for the required spacing causes any lose of content (unless an accessible alternative is provided)
2.5.3 Label in Name (A): if truncated visible labels do not match or are not contained within the components accessible name. For example: "Apply for a new passport" does not contain the text "Apply..."
3.3.2 Labels or Instructions (A): if form labels or instruction are truncated to the point where they lose meaning

What to do instead

Avoid truncating text wherever possible. Truncation adds barriers and often causes confusion for everyone.

In most cases, truncation can be designed away by:

Letting text wrap naturally
Using flexible layouts instead of fixed widths
Allowing containers to grow with content
Rethinking whether all content needs to fit in one line

If content needs to be hidden, use clear and accessible patterns such as the Disclosure pattern, that work with keyboard, touch, and screen readers.

When dealing with long unbroken strings/words, where you may not have control over the content (e.g., user generated content or content pulled in from 3rd party integrations), rather than trucating, hyphenate the word and allow it to wrap:

.wrap-text-with-hyphens {
  overflow-wrap: break-word;
  hyphens: auto;
}

In rare cases where truncation is unavoidable, provide an obvious and accessible way to view the full content. This might mean repeating the full text nearby or offering a clear accessible control to reveal it.

Truncation is a design choice, not a technical limit. By prioritising clarity over rigid layouts, we can create interfaces that work better for everyone.

A simple example of how accessibility helps everyone

2025-08-28T00:00:00Z

When accessibility is your day job, you all too often see accessibility issues on the web that make you wince. Today was one of those days.

I was cooking tea (or dinner if you're not from Yorkshire). The kids were telling me about their days while I was cooking up their favourite spaghetti bolognese. I'd had my car serviced earlier in the day. I got a text message from the dealer that linked to a "vehicle health check" video - where they walk you around the car and talk you through any potential issues. As the kids dashed off to play outside, I grabbed my phone with one hand, while trying not to burn the mince I was frying.

I hit the link expecting to see the video...

The problem

Instead, I was taken to a form where I needed to enter my car registration number, postcode and, mobile number.

The first red flag: the page wasn't responsive. Nothing stacked neatly into a single column - the usual mobile-first/responsive pattern.

Ignoring this, I tapped on the registration number input, which is when things got frustrating.

The screen shifted and zoomed slightly so that labels disappeared off the left side. This happened for every field: car reg, email and mobile number.

Trying to type one-handed while cooking and keeping an eye on the kids, I had to constantly scroll left and right just to remind myself which field I was in. Frustrating, especially when you know how easily this could have been avoided. Not to mention this is also a failure of WCAG 1.4.10 Reflow (AA).

For me, it was just an annoyance. But for someone with motor control challenges or cognitive impairments, this would have been a much bigger barrier.

Digging deeper

Later in the day, I decided to take a deeper look at the page to see what other issues lurked. After inspecting the page in Chrome DevTools, more issues were found.

Page basics

No language set on the <html> tag, failing WCAG 3.1.1 Language of Page (A)
No page landmarks at all, potentially making navigation harder for screen reader users
No initial zoom level set due to missing initial-scale=1.0 on the viewport meta tag's, which can cause zooming and layout problems

Forms and labels

Labels weren't programatically associated with inputs (missmatched for and id values), failing WCAG 1.3.1 Info and Relationships (A) and 4.1.2 Name, Role, Value (A)
No autocomplete values on email or mobile inputs, failing WCAG 1.3.5 Identify Input Purpose
Form errors were communicated by text but were not programmatically associated with inputs, arguably failing WCAG 1.3.1 Info and Relationships (A)

Content and layout

Header links and images visible at wider screen widths were hidden on mobile, failing WCAG 1.4.10 Reflow (AA)
Empty headings were present, failing WCAG 2.4.6 Headings and Labels (AA)
Linked images had no accessible names (no alt text, ARIA or visually hidden text), failing WCAG 4.1.2 Name, Role, Value (A)
Text was small and the default iOS focus outline was low contrast, making everything harder to see and use.
Percentage-based widths on labels and inputs with no media queries for smaller screen sizes / higher zoom levels (lack of responsive design)

What should have been done

This is a classic case where accessibility, usability, and good design overlap. These "vehicle health checks" are sent out by SMS, so almost everyone opening them will be on a phone. At the very least, the team should have tested the user journey on mobile, with and without a screen reader. Had this been done, almost all of the issues mentioned would have been caught.

None of of the issues are hard to fix, it's standard responsive, accessible design.

Here's a simple CodePen showing how the page could look, had it been built with accessibility in mind.

See the Pen Example responsive dealer sign in by James Jacobs (@jamesjacobs) on CodePen.

Conclusion

When you're designing, building, or testing something, don't just check it on your desktop. Try the full user journey on different devices and screen sizes, and against the baseline WCAG provides, using tools like screen readers, speech recognition, and built-in features found in almost all browsers and operating systems, such as zoom or magnification.

Doing this doesn't just help people with permanent disabilities - it makes life easier for anyone juggling everyday chaos: cooking dinner, sorting the kids, or trying to type one-handed. That's situational impairment in action, and this story is a perfect example.

Accessibility isn't just about compliance. It's about making things work for real people, in real life. And real life is messy: kids, cooking, one hand free. When you design, develop and test with that in mind, everyone wins.

Oh, and you'll be happy to know, I didn't burn the tea and the kids enjoyed spaghetti bolognese for the millionth time!

Building a lasting accessibility strategy: Part 4

2025-08-01T00:00:00Z

In part 3, we looked at how to embed accessibility into the development lifecycle, going beyond compliance, design systems and how different roles can contribute. In this final post of the series, we'll wrap things up by focusing on audits, user testing, ongoing monitoring, and creating a living roadmap to keep accessibility moving forward.

As before, I'll keep using the word "website" as a placeholder for digital products, services, platforms, and apps.

Accessibility audits

In-depth, human-led accessibility audits are an important part of any accessibility strategy and programme. They involve testing a website against WCAG success criteria, as well as recommending improvements beyond WCAG, to uncover barriers that users may face. Audits should be carried out by people with detailed technical knowledge of accessibility standards and assistive technologies.

Issues identified in an audit should be prioritised and addressed. And while WCAG isn't the be-all and end-all of accessibility, it provides a solid and consistent baseline for testing.

It's important to remember that audits provide only a snapshot in time of a website's accessibility. Things change quickly - new content, features, and behaviours can introduce fresh issues. For this reason, audits should be seen as one part of the solution. Real progress comes from combining audits with culture change, staff knowledge, and embedded practices.

How to audit

Accessibility auditing is a specialised area, and a full deep dive is beyond the scope of this post (though I plan to cover it in a future one). For now, here's a high-level overview for anyone with limited exposure to audits.

Most organisations that perform audits use their own methodology, but these often align with the WCAG-EM (WCAG Evaluation Methodology). WCAG-EM provides structured guidance on evaluating how well websites conform to WCAG through manual testing.

Auditing an entire site with thousands of pages, components, interactions, and states would be impractical. Instead, audits typically focus on a representative sample of pages and key user journeys, which are tested against each WCAG success criterion using a mix of automated tools, assistive technologies, and manual testing.

Common tools include:

Deque Axe
Site Improve
IBM Equal Access
WAVE
Microsoft Accessibility Insights
Colour contrast checkers
Screen readers: Mac/iOS VoiceOver, NVDA, JAWS
Speech recognition software: such as Dragon NaturallySpeaking
Magnification software

Of course, full website audits can be carried out if necessary (and if your have the time and resource) by breaking the audit into phases, with each phase focusing on a different area of the website.

It's a good idea to perform audits periodically - to catch new issues and stay on top of compliance - alongside accessibility testing that's embedded into your development lifecycle. If you don't have in-house expertise, many organisations provide accessibility auditing services, such as AbilityNet and TetraLogical.

User testing

Audits, automated tools, and compliance checks all have their place in an accessibility strategy. They can highlight technical issues, flag WCAG violations, and provide a baseline for improvement. But none of these can substitute for real-world testing by people with disabilities.

It often comes as a surprise to teams new to accessibility that a website can technically conform to WCAG standards while still including barriers for users. For example, navigation may be technically operable but exhausting for someone using a screen reader, or a form may be technically accessible but confusing for someone with cognitive impairments. Only by involving real people can you uncover these gaps between compliance and experience.

The feedback from disabled users is super valuable: it provides direct insight into how well your design supports independence, efficiency, and dignity. No amount of internal testing can replicate lived experience.

If you don't yet have a direct connection to disabled users, there are organisations that can help, such as Shaw Trust Accessibility Services and RNIB. These partnerships can bring powerful insights to your teams and build empathy in the process.

User testing is often the difference between a product that is compliant and one that is genuinely inclusive.

Track and monitor progress

If you're not measuring accessibility, you won't know whether you're improving. Tracking progress helps demonstrate impact, keeps accessibility visible across the organisation, and provides evidence for leadership buy-in. It also ensures accountability - accessibility isn't something you can "set and forget."

A balanced approach works best:

Automated testing in the build pipeline: tools like Cypress + cypress-axe can flag common issues during development. Track trends over time to show improvements or spot regressions.
Ongoing automated monitoring: services like Silktide and Siteimprove provide regular scans and dashboards that highlight trends. Remember, automated tools only catch around 30% to 40% of WCAG issues, so this should complement, not replace, manual testing.
Manual technical audits: periodic human-led accessibility reviews against WCAG and beyond give a more accurate picture of barriers automated tools may miss.
User testing with people with disabilities: the most valuable feedback comes from real users - they'll uncover issues that no automated or technical audit will ever catch.
Support and feedback channels: log accessibility issues raised through customer support, feedback forms, or social media.
Issue tracking: keep accessibility issues in your normal project management tool (Jira, Trello, Azure DevOps) so progress is visible.
Roadmap and backlog updates: feed findings back into your accessibility roadmap to keep work prioritised.
Transparent reporting: share progress and gaps with your teams and leadership. This builds trust and keeps accessibility high on the agenda.

It's just as important to celebrate wins as it is to flag challenges. Recognising progress keeps teams motivated, while openness about gaps prevents complacency.

As accessibility advocate Meryl Evans says: "Progress over perfection." Accessibility is a journey, not a checkbox. The goal is steady improvement, not ticking every box at once.

Create a living accessibility roadmap

Once you know where you are on your accessibility journey, the next step is to map out where you want to go. A living roadmap helps set clear expectations for product owners and leadership, and it should be something that's visible and shared widely across the organisation.

Think in timeframes: what do you want to achieve this year, next year, and even in 5 years? Your roadmap should cover core products and design systems, with specific items pulled into product roadmaps as priorities shift.

The key word here is living. A roadmap isn't a static document. It should evolve as your organisation learns, grows, and makes progress.

Conclusion

That brings us to the end of this series of posts - I hope you've found them useful. Accessibility strategy is a big topic, and one I could keep writing about (and probably will in the future).

Building a lasting accessibility programme is not a quick or easy task. There will be obstacles, and it takes persistence, resources, and sometimes a thick skin. But the reward is worth it: a culture, a team, and a website that truly includes everyone.

Futher reading

Building a lasting accessibility strategy: Part 3

2025-07-24T00:00:00Z

In part 2, we covered how to get people involved, raising awareness, accessibility champions, and the importance of internal resources.

Now that you have people on board, the next step is making accessibility part of how you build and maintain your products. That means going beyond compliance, weaving accessibility into the development lifecycle, making good use of design systems, building a dedicated accessibility function, and ensuring every role contributes to more inclusive experiences.

As before, I'll keep using the word "website" as shorthand for digital products, services, platforms, and apps.

Understand technical compliance, but aim higher

A lot of organisations stop at WCAG AA compliance, since it's the minimum required by most accessibility laws. The problem is that this approach often ignores AAA requirements and best practices outside WCAG that can make a big difference to real people.

AAA criteria are especially helpful for people with cognitive, visual, or auditory impairments. For example:

1.4.6 Contrast (Enhanced): higher contrast ratio for text, improving readability for people with low vision
2.4.9 Link Purpose (Link Only): ensures link text makes sense in isolation, which helps screen reader users
3.1.5 Reading Level: can help people with dyslexia and other learning disabilities

It's true that not all AAA criteria are practical for every website. WCAG itself says Level AAA should not be required across the board. But aiming for AAA where possible is valuable. WCAG itself notes:

It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA success criteria for some content.

Beyond WCAG, additional guidance and recomendations exist, such as the work done by the W3C's Cognitive and Learning Disabilities Accessibility Task Force (COGA TF), for example, Making Content Usable for People with Cognitive and Learning Disabilities. The excellent Inclusive Design Principles are another useful reference.

Simple design choices can make a big difference too. A decorative font might technically pass contrast checks but still be hard to read for people with dyslexia or low vision. That's why testing with real users is so important: a site can meet WCAG yet still include barriers.

Compliance is the baseline. A stronger approach is to define your own accessibility standards, combining AA, selected AAA, and best practices that fit your users' needs.

Embed accessibility into the full development lifecycle

Accessibility isn't something to tack on at the end, nor is it just one person's job - everyone can and needs to contribute. It should be integrated across the entire development life-cycle. Set role-specific expectations and requirements. For example:

Product owners/Project managers: prioritise accessibility work, ensure it's included in roadmaps and make space for it in sprints. Write accessible user stories and acceptance criteria.
Designers: follow inclusive design patterns from the start, including accessible colours, target sizes, layouts, user journeys and interactions that work for a wide range of users.
Developers: use accessible components and semantic HTML. Run basic accessibility checks before passing work to testers. Write accessibility test assertions with the same priority as unit and end-to-end (e2e) tests. Include accessibility checkpoints in your Definition of Done (DoD)
QA/Testers: catch issues through automated tools and manual testing with assistive technologies. Contribute to any automated accessibility test suite.

Other roles, not specifically involved in the typical development lifecycle can and should also contribute to promoting accessibility:

Content authors: write clear, concise content with headings, plain language and descriptive link text so information is easy to understand and navigate
Customer support: listens to feedback from users, especially those with disabilities, and passes insights back to product teams
Marketing: produces campaigns and assets that are accessible and easy to engage with, from alt text on images to accessible PDFs and video captions
Leadership: sets expectations, removes barriers and gives teams the time and resources they need to do accessibility properly

Accessibility works best when it's seen as part of everyone's responsibility, not a single team's task. When each role contributes, accessibility becomes a natural and sustainable part of your organisation's culture. The goal is to make accessibility a habit, not a one-off task.

Design systems and component libraries

If you're not using a component library, start now. If you are, make sure accessibility is built in by default.

These reusable UI components should include all the necessary accessibility considerations - semantics, color contrast, keyboard support, ARIA (where necessary - remember the first rule of ARIA), focus styles - the lot. Broader accessibility guidance can be covered in your design system, as well as component specific guidance and expectations.

The real power of a component library is that updates cascade across your whole product. Fixing one component can fix hundreds of instances in one go. That makes it a powerful tool for rolling out accessibility improvements, and a natural place to start when auditing or testing your site.

An accessible component library doesn't guarantee a fully accessible product, but it gives teams strong foundations to build on.

A dedicated accessibility team

Many organisations don't have a dedicated accessibility team or lead, and instead rely on individual champions scattered across departments. While this grassroots energy is important, having a dedicated team can significantly accelerate progress.

A dedicated accessibility team can:

Set direction: define the organisation's accessibility vision, strategy and standards
Provide expertise: fill knowledge gaps across teams by offering guidance on design, content and development best practices
Collaborate: with product management, design, and development teams to define accessibility requirements and acceptance criteria
Consult: on scope of effort, user impact, and regulatory priorities related to accessibility
Deliver training: run onboarding, refresher sessions and role-specific training tailored to different functions
Support projects: partner with product teams to review designs, test features and advise on complex accessibility challenges
Build resources: maintain documentation, component libraries and internal guidance to ensure consistent approaches
Lead audits and monitoring: coordinate testing and reporting, making sure accessibility is continuously tracked and improved
Act as advocates: champion accessibility at all levels, helping it stay visible and properly resourced

The presence of a team also shows that accessibility is a real priority, not just something left to volunteers. It gives people a clear place to go for advice and reduces the burden on individual teams.

What a dedicated team can look like

Smaller organisations: A single accessibility lead or specialist who drives initiatives, supports teams, and acts as the main point of contact
Mid-sized organisations: A small accessibility team (2–3 people) who split responsibilities across training, audits, design support and development guidance
Larger organisations: A central accessibility function with specialists in design, development, content and assistive technology, often paired with accessibility champions embedded across departments

Whatever the size, the team needs both visibility and authority. They should be able to influence priorities, shape processes, and work with leadership to ensure accessibility is resourced and sustainable.

The business case

Investing in a dedicated team pays off quickly. It helps avoid costly retrofits or lawsuits, creates reusable resources, and drives customer loyalty by making products usable by more people. In short: it helps everyone work smarter, not harder.

In part 4, we'll wrap things up by covering testing, measuring and monitoring accessibility.

Building a lasting accessibility strategy: Part 2

2025-07-18T00:00:00Z

In part 1, we looked at how to get started by defining your goals, building a plan and getting leadership buy-in.

With leadership on board and a plan in place, the next step is embedding accessibility into your organisation's culture. Real success doesn't just come from checklists or audits - it comes from people. In this post, we'll look at how to get everyone on board, raise awareness, find allies, build a champions network, and provide the education and resources teams need.

To keep things simple, I'll keep using the word “website” as a stand-in for digital products, services, platforms, and apps.

Getting everyone on board

Accessibility can't sit on one person's shoulders. It works best when everyone - designers, developers, testers, product managers, and leadership - sees it as part of their role. It should be part of your team's mindset, not an afterthought.

In my experience, understanding varies hugely from person to person, ranging from zero awareness to deep expertise. The challenge is that accessibility can be complex, subjective, and often not covered in typical design or development courses.

The tricky part is that awareness levels vary a lot. Some people have never heard of accessibility beyond “screen reader stuff”. Add to that the fact that accessibility can feel complicated and isn't always taught in design or development courses, and it's easy to see why it gets overlooked.

Accessibility? That's aria labels and screen reader stuff right?

— Anonymous developer

The biggest barriers I usually see are:

Lack of understanding of its importance and impact
Limited knowledge, training, resources, and documentation
Difficulty getting user feedback from real people with disabilities

Knowledge and awareness are important, but embedding accessibility requires cultural support too. Culture change takes time and effort, but when people feel engaged and passionate, the impact is huge. Tying accessibility into existing initiatives, like DEI programs, can also help build momentum.

Raising awareness

If awareness is low, interactive and engaging activities can make a big difference:

Lunch and learn: short sessions focused on one topic. For example, keyboard accessibility - before the session, find three websites with known keyboard issues, then challenge attendees to complete tasks using only their keyboard. Discuss what they found frustrating and why it matters.
Lived experience speakers: invite people to share first-hand accounts of living with disabilities and how accessibility impacts daily life.
Empathy labs: designed to help participants understand and, to some extent, experience the challenges people with disabilities face when using digital products and the web. These labs often use personas and simulation equipment to demonstrate what it's like to navigate with different impairments or assistive technologies. While valuable for building empathy, they should never replace testing with real users who have disabilities.

Even a short video can make a big impact when it comes to raising awareness. One of my favourites, which I often share in accessibility training, comes from Which Magazine and AbilityNet. In it, Adi Latif, a blind digital accessibility consultant, demonstrates the challenges of booking airline tickets using a screen reader.

Finding allies

Many teams already have people who are passionate about accessibility or disability rights (often because of personal experiences), even if they aren't yet familiar with accessibility or technical requirements. Find those allies and encourage them to:

Asking accessibility questions
Celebrating accessibility wins
Sharing user feedback
Talking about accessibility in meetings, Slack/Teams channels, stand-ups, and retrospectives.

Culture change doesn't happen overnight, but it starts with small, consistent actions.

Accessibility champions

Once you have allies, keep the momentum going by creating an accessibility champions network. This could be as simple as a monthly catch-up to share successes, challenges, and learning, or something more structured with defined learning paths. Including a senior leader in the network increases visibility, helps remove barriers, and reinforces the importance of the work.

In my own work, I started a champions network with a two-hour session every other month: the first hour was training on a topic chosen by attendees, and the second was an open discussion. This mix of learning and sharing gave champions the confidence to become the go-to accessibility contacts in their teams.

Resources on building a champions network:

Education and resources

Awareness is important, but people also need practical knowledge. If your team doesn't know how to build accessible things, they won't. I've had great success tackling this through:

Accessibility training for new starters
Role-specific training (e.g. for designers, developers, testers)
Regular refresher sessions (e.g. quarterly)
Internal guides and knowledge base
Dedicated Slack/Teams accessiblity channel for questions, discussions and sharing

Internal resource center

An internal accessibility resource center can be incredibly powerful for sharing consistent guidance, accessible component patterns, guides and other related content. Built well, it acts as a single source of truth for your teams and provides a simpler alternative to technical documentation like WCAG.

In my current role, we built an internal accessibility resource center that covers:

Internal accessibility standards: including WCAG AA, some AAA and best practices beyond WCAG
Accessible UI components and patterns: expected HTML, CSS, JavaScript, ARIA and keyboard interaction behaviour for components and patterns used across our platform
Accessible content creation: non-technical guidance for content creators
Testing guidance: covering light touch checks, full technical audits against WCAG and use of assistive technologies like screen readers, speech recognition and magnification
Relevant laws and regulations: those that apply both to the organisation and its customers

If you don't yet have the knowledge to create this internally, some organisations offer subscription-based accessibility knowledge bases, such as Deque and the TPGI ARC KnowledgeBase

Once you have a solid plan for building a culture focused on accessibility it's time to look at how accessibility can be embedded into existing processes across the full development lifecycle, which we'll cover in part 3.

Building a lasting accessibility strategy: Part 1

2025-07-10T00:00:00Z

Welcome to the first in a series of posts where I'll share my experiences of building a lasting accessibility strategy and programme at a software company whose platform is used by millions of people worldwide. Building a successful, sustainable accessibility strategy takes time, patience and a lot of hard work. There's no single "right" way to do it - what I'm sharing here is what worked for me. Feel free to take the bits that resonate and adapt them to your own organisation.

To keep things simple, I'm going to use the word "website" as a placeholder for digital products, services, platforms and apps.

Laying the foundation

Knowing where to begin with such a big task can feel overwhelming. The best place to start is with the basics: establish the why, define the goal, gather supporting data, and identify your current areas of weakness.

Define the goal

Before diving into the current state of accessibility in your organisation, take a step back and ask: in an ideal world, what would accessibility look like here? That vision is your starting point.

Your goal might be something like "everyone can use our website, no matter their ability or technology" or "we meet WCAG 2.2 AA across all websites." From there, break the big vision into smaller, practical goals - both short and long term. For example: "Update our component library to meet WCAG 2.2 AA conformance."

Whatever the goals are, they should be clear, achievable, and something people can rally behind. If they're too vague or too ambitious, it'll be hard to make progress. These goals then become the foundation of your accessibility roadmap. Don't worry if you don't yet know every area that needs attention - that discovery will come in the next step.

Find the gaps

Once you have a goal in mind, look at your organisation's current accessibility practices. How well is accessibility built into everyday processes? At this stage, you don't need to dive into detailed WCAG failures or full audits. That said, if you already have an accessibility audit of your website, it can be a useful reference for spotting where processes are breaking down.

The focus here should be on processes and gaps. A survey can be a great way to spark conversation, collect perspectives, and build a clearer picture of your accessibility landscape. The goal is to uncover barriers or knowledge gaps that might be holding your teams back.

Example survey topics:

General awareness of accessibility
How accessibility is prioritised within their role and team
Existing accessibility processes or considerations in their team
Understanding of relevant laws, regulations and directives - e.g. for UK public sector bodies: Public Sector Bodies Accessibility Regulations (PSBAR); in the US: ADA Title II or Section 508; in the EU: European Accessibility Act (EAA)
Awareness of the user impact of accessiblility
How their role can directly or indirectly affect accessibility
Understanding of technical guidelines such as WCAG 2.2
Knowledge of accessibility testing and assistive technologies

Send the survey to as many people as possible across different roles - including frontline contributors like designers, developers, and testers, as well as those who influence priorities, such as product owners, project managers, and senior leaders. Follow up with conversations to unpack the findings. For larger teams, consider tailoring survey questions to specific roles or departments.

Gather useful data

Solid data can help counter common misconceptions, such as the dreaded "Disabled people don't use our website", and strengthens the case for investment in accessibility. It also helps get leadership on board by showing the scale and impact.

Around 1 in 4 people in both the UK and US have some form of disability. That's not a niche - it's a significant share of your audience.
Globally, 1.3 billion people experience significant disability (16% of the world's population, according to the WHO).
In the UK, disabled households represent an estimated £274 billion in annual spending power (often called the Purple Pound). In the US, it's over $490 billion.
WebAIM's 2024 study of the top 1 million websites found that 96% had detectable WCAG failures on their homepage.

Useful sources:

Building a plan

Once you know where you stand and where the gaps are, the next step is to create a plan to address them. This usually includes a mix of resources, training, and ongoing support, such as:

Internal resources like accessibility guides or knowledge bases
Awareness-building activities (lunch-and-learns, empathy labs, talks from lived-experience speakers)
General accessibility awareness training
Role specific training for designers, developers, testers and other relevant groups
Periodic refresher training
An internal network of accessibility champions
Dedicated accessibility Slack/Teams channels
A designated accessibility lead or team
Testing, auditing and monitoring

Accessibility maturity models

Accessibility maturity models can be useful throughout the journey of creating an effective accessibility strategy.

Rather than focusing only on technical compliance (e.g. whether your site meets WCAG 2.2 AA), they provide a structured way to evaluate how well accessibility is embedded across your organisation—through leadership, culture, training, processes, and technology.

They usually break things down into categories and stages of maturity, from ad-hoc to developing, established, and optimised. They help you:

Get a baseline view of where you are today
Identify gaps and areas to improve
Set realistic goals for growth
Track progress over time
Communicate achievements to leadership in a clear, strategic way

Two examples worth looking at are:

W3C Accessibility Maturity Model – A high-level framework with seven dimensions (including communications, knowledge, and culture) measured across stages from Inactive through to Optimise. It's designed to help organisations of all sizes embed accessibility into everyday operations and align with governance and compliance.
AbilityNet's Digital Accessibility Maturity Model (DAMM) – A more practical toolkit designed to help organisations carry out structured assessments, set future goals, and create a roadmap of improvements. DAMM is available in a general form and a tailored version for higher education, making it adaptable to different contexts.

The big benefit of maturity models is that they help shift thinking away from one-off fixes toward long-term cultural change.

Existing issues

At this stage, you probably won't have a full picture of all the accessibility issues in your website, and that's okay. Many organisations fall into the trap of starting with full audits, which can lead to endless cycles of technical fixes without addressing the root causes: knowledge gaps and culture.

Audits and testing are important, but right now the priority is laying the foundations that support ongoing accessibility. Light-touch audits, however, can still be useful to highlight a few issues and provide tangible examples that help build the case with leadership.

Leadership buy-in

Once you've identified the gaps, created a clear plan, and gathered supporting data, it's time to get leadership on board.

Without strong support from the top, accessibility efforts often stall. Leadership buy-in sets expectations, signals commitment, and helps embed accessibility into everyday practice.

When approaching leadership, come prepared with:

A clear plan to addressing gaps
A list of needs (budget, visibility, endorsement, barrier removal)
A strong business case (statistics, user stories, competitive benchmarks)
A reminder: accessibility is both the right thing to do and the smart thing to do

The why

Remember, many leaders won't be deeply familiar with accessibility. Keep it simple and cover the essentials:

What accessibility is and why it matters
Statistics: e.g. 1 in 4 people in the UK have a disability - meaning almost every website serves disabled users
Benefits for everyone: permanent, temporary, and situational impairments affect all of us
User feedback: share real stories from disabled users who encountered barriers
Benchmarking data: if relevant, e.g. Silktide index rankings

The business case

Highlight the advantages, the risks of inaction, and the broader impact:

Better customer experiences: accessible websites and content are often faster, simpler, and easier to use for all users - not just disabled people. Everyone benefits from clearer design and smoother interactions.
Stronger loyalty: when organisations take accessibility seriously, they earn the trust of disabled customers. Research shows that disabled users tends to be more loyal and more likely to recommend businesses that truly include them.
Reduced risks: the cost of getting accessibility wrong is rising. Poor accessibility can lead to frustrated users, negative press, and even legal action. Laws and running like the UK's Public Sector Bodies Accessibility Regulations (PSBAR), the US's ADA, and the European Accessibility Act (EAA) require compliance with standards like WCAG.
Financial aspect: excluding disabled customers isn't just unfair, it's expensive. UK businesses lose an estimated £2 billion every month by not meeting their needs (The Purple Pound). On top of that, it's much cheaper to build accessibility in from the start - IBM found that fixing issues after launch can cost four to five times more.
Future-ready design: Accessibility doesn't just help people - it also helps technology. As organisations invest in AI and automation, accessible content is easier for machines to understand and work with, making your digital services more future-proof.

Alignments with leadership goals

Show how accessibility supports your organisation's existing values and priorities, such as "putting the user first" or DEI (Diversity, Equity, and Inclusion).

Be clear about what you need

Finally, set out the commitments required, such as:

Budget for training, resources, or dedicated accessibility roles
Ongoing support from senior leadership
Visible endorsement in communications, decision-making and cultural change
Inclusion of accessibility in KPIs, OKRs, roadmaps, and review processes

Once you have leadership buy-in and a solid plan it's time to start building the culture, which is covered in part 2.

Embedding manual accessibility testing in frontend development teams

2025-06-02T00:00:00Z

Often when discussing accessibility testing, the focus is on technical accessibility audits, testing processes or the requirements of individual WCAG success criteria. While these things are important, they are require a certain level of technical knowledge, often from people whose day to day role is accessibility testing. There are many parts to an effective accessibility strategy, but one sometimes overlooked part is having your frontend developers, not just those working on design systems and component libraries, directly involved in accessibility testing as part of day to day features development and bug fixes.

Involving developers in accessibility has several benefits:

increases the teams level of accessibility awareness and knowledge
catches issues or prevents them outright before the testing phase
reduces testing time
ties in with a "shift-left" or "accessibility-first" approach

Here are steps I use when working with frontend teams.

First steps

Define basic manual tests

These are basic tests that can be documented in a checklist and require little accessibility knowledge. They should be quick and easy to perform.

Example tests:

Keyboard: using the keyboard only, tab through the page, making sure all interactive elements can be navigated to and interacted with solely via the keyboard
Focus indicator: check the keyboard focus indicator is visible against all background and does not disappear, or get completely hidden by other elements, at any time when tabbing through the page or interacting with elements via the keyboard
Focus order: check the order that items gain keyboard focus is logical
Focus traps: check keyboard focus doesn't get trapped within an area of page without a clear method of escaping the trap
Content on hover/focus: check any content displayed on hover or keyboard focus can be hovered over, dismissed without moving the pointer and doesn't disappear after a few seconds

See my basic accessibility tests for developers guide for more suggestions.

Use an accessibility browser extension

Install an accessibility focused browser extension such as AXE or ARC Toolkit. These are quick and easy to run (typically one click) and generally provide enough detail to identify issues and the related fixes.

Use an accessibility linter

Linters are commonly used by developers to analyse and identify code issues. Linting code is very common for development teams wanting to ensure code meets team standards and quality. Many configurable accessibility focused linters also exist for different languages and frameworks that can catch potential issues at the code stage, for example AXE Accessibility Linter.

Most linters include a configuration file that can be committed to a project and used by all developers involved, providing a uniform set of checks. This requires little setup and fits in easily with what is likely already a standard team process.

Check:

All interactive elements have descriptive labels (accessible names)
No parts of the page is skipped by the screen reader
Images have meaningful alt text (unless they are purely decorative)
The visual order of the page is the same or similar to the reading order

These are basic checks. I cover more indepth tests in my how to test with a screen reader guide. Full screen reader testing should be handled by trained testers.

Developers using Windows can use the free, open source NVDA screen reader. VoiceOver comes preinstalled on macOS.

Tip: run a workshop

Run a "screen reader basics" workshop with the team before getting them involved with screen reader testing. Using a screen reader for the first time can be confusing as there is little to no UI.

Consider accessibility in code reviews

Code reviews often focus on standards, patterns and potential bugs. Add accessibility to the list of considerations. This works well if accessibility is included in your internal coding standards.

Example checks could include:

enforcing semantic HTML e.g. using <button> rather than <div role="button">
ensuring correct use of ARIA e.g. flagging the use of aria-label on a generic element such as <div>
ensuring accessibility tests have been written for a new feature

This does require that developers have some level of accessibility knowledge. Role specific training can help with this.

Build checks into acceptance criteria

Most developer teams have either acceptance criteria or a definition of done. Incorporate these checks to set expectations and make it a part of everyday processes.

Longer-term improvements

Provide accessibility resources

Having a centralised accessibility knowledge base that provide guides, patterns and component examples for developers to consult can go a long way into both increasing team accessibility knowledge and confidence while also reducing the amount of accessibility issues that make it into the test phase.

Training

In my current role, I regularly run accessibility training for developers. Both "Introduction to web accessibility" training sessions as part of new starter inductions and periodic role specific training for designers, developers and testers. We run the role specific training sessions at least twice a year to help in maintaining and refresh knowledge. If you don't have an internal accessibility lead or specialist that can run these for you, consider bringing in external trainers. If you're in the UK I recommend AbilityNet and Shaw Trust Accessibility Services.

Monitor issues found at test

Actively monitor the accessibility issues found in the test phase and feed this back to developers so that, where appropriate, developer tests can be expanded to include any common issues.

CI/CD pipeline

Many development teams use some form of Continuous Integration (CI) and Continuous Delivery/Deployment (CD). These typically run tests (unit, regression, integration etc) as part of the process. Automated accessibility tests can also be run at this stage. Various tools exists such as Cypress-AXE.

In addition to other tests, have developers write accessibility tests that run at build time, as part of feature/story development and bug fixes.

Have a dedicated accessibility champion on the team

Accessibility champions promote accessibility and supports others on the team. They advocate for and advise on accessibility. In addition to any internal knowledge base or accessibility team, they can serve as the initial "go-to" for accessibility related advice and knowledge.

Creating and maintaining a network of accessibility champions across your organisation is a big subject which I'll cover in another post.

Hello World

2025-05-02T00:00:00Z

For a long time I've been wanting to get back into regular blogging. Life often gets busy - work, family, children etc can leave little time for other things. Back in the early 2010's I used to blog on my exploration into developing "hybrid" mobile apps, I then had a spate of posts on Medium - both of which I thoroughly enjoyed writing. These days my primary focus is digital accessibility. So, going forward, this site will act as a dumping ground for my thoughts, ideas and discoveries as well as offer resources to people starting out in digital accessibility. It's also going to be a creative playground, allowing me to experiment with different technologies - at the moment, this site is built with 11ty.

In ~2008, when I first started learning about web accessibility, I found it difficult to find authoritive technical guides and documented patterns. Many of the resources and articles available were contradictory and typically focused on the basics, such as colour contrast. Many more focused on advocating for accessibility (which is 100% important) but as I was involved in building design systems, component libraries and enterprise-level UIs I wanted technical code-focused examples. Finding tried and tested solutions and examples of certain patterns was challenging.

With that in mind, I intend to add regular posts and guides on digital accessibility - with the aim of building up a resource for people new to accessibility.

At the time of writing (a sunny but cold day in January 2025), the web accessibility community has come on leaps and bounds with some amazing minds putting out regular, highly detailed content (which I aspire to do).

Here's a small list of links to some of the, in my opinion, best accessibility related content creators and professionals on the web:

Adrian Roselli
Steve Faulkner
Eric Eggert
Sara Soueidan
TPGi Technical blog
Tetralogical
and many others can be found on a11y-webring.club

In addition, here's some resources I'd encourage everyone interested in web accessibility to become familiar with (more on these in another post!):

Blog posts - jamesjacobs.me

Setting up Windows Screen Readers on a Mac

Why test in multiple screen readers

Setting up a Windows Virtual Machine

Download Windows 11

Buy a Windows 11 licence key

Set up UTM and install Windows

Install NVDA

Visual Highlight

Speech Viewer

Install JAWS

Speech History

Highlight Virtual PC Cursor

Configure the keyboard

Option 1: external PC keyboard

Option 2: remap insert key

Avoid using Caps Lock

Selecting the keyboard layout

JAWS keyboard layout

NVDA keyboard layout

Using Function (F) keys

Browser and screen reader combinations

Set up complete

Useful links

Deep dive: crafting accessible links

Foundations

Accessible names and roles

Use semantic markup

Links vs buttons

Writing accessible link text

Make the destination clear

Don't: use ambiguous link text

Do: make it clear where the link leads

Keep link text concise

Don't: link unnecessary words

Do: link enough to preserve meaning

Use consistent wording

Don't: use different link text for the same destination

Do: be consistent with link text

Include the file type and size in the link text

Do: inform the user of the file type and size

Avoid using raw URLs as link text

Don't: link RAW URLs

Do: use clear descriptive link text

Non-text links

Icon links with visible text

Icon links without visible text

Linked images

Don't: describe the image in the alt text

Do: use alt text to label the link

Link behaviour

Avoid opening links in new tabs (warn users if you do)

Don't: open links in new tabs unnecessarily

Do: warn users when a link needs to open in a new tab

Disabling links

Styling considerations

Visually differentiate text links

Don't: rely on colour alone

Do: use a secondary visual cue

Text contrast rules apply

Use a highly visible focus indicator

Don't: disable focus indicators

Do: use a highly visible focus indicator

Make links large enough to comfortably activate

Hover styles

Common patterns to avoid

Avoid pairing a heading with a generic link

Avoid linking an image and nearby text to the same place

Don't use the same link text for different destinations

Conclusion

The accessibility pitfalls of truncating text

Why text is truncated

How is text truncated

CSS (most common method)

JavaScript or server side truncation

Who is affected

Issues caused by text truncation

Effects on text style modification

Increased font size

Increased text spacing