Assistive Technology posts

Our Common accessibility misconceptions series sheds light on many misunderstood aspects of accessibility.

Testing for accessibility is often misunderstood. Teams either overestimate what tools can do, underestimate their own role, or assume testing is something that happens once only, at completion of the development process.

In this post we tackle some of the most frequent misconceptions about accessibility testing.

Most people working in digital are aware of the Web Content Accessibility Guidelines (WCAG) and know they can help make digital products work for everyone. However, the way the guidelines are discussed often leads to mixed assumptions about what they cover and how they should be used.

Screen readers are familiar to many in digital, but how they work in practice can be less clear. In this post, we shed some light on the topic.

Imagine being in a department store that sells clothes from multiple brands and having a personal shopping assistant to help you select the clothes you want to buy. As a blind person, that's about the only way it's possible to go clothes shopping, independently at least, but few stores offer such a service, so you resort to shopping online.

This post provides an overview of common assistive technologies (AT) used by people with seeing, hearing, moving, and thinking disabilities. It also explains what adaptive strategies are, and how these approaches work together to support accessibility and inclusive experiences.

With the addition of Gez Lemon to the editing team, work continues on expanding and improving the HTML and screen reader support information.

By prioritising semantic HTML and offering keyboard-friendly alternatives for complex interactions, you help create a more inclusive experience for people who use a keyboard.

In 2025, Artificial Intelligence (AI) and Large Language Models (LLM) like ChatGPT, Gemini, Claude, and DeepSeek are being used for everything. Writing emails. Generating code. Even applying for jobs. But, can they write good text descriptions for images?

Meet Josh, a sportsman who has spinal muscular atrophy. Between training for the Paralympics and his busy day job, Josh talks to us about how navigating the web is constantly evolving, how he adapts to various assistive technologies, and his hopes and concerns for artificial intelligence (AI).

In this post, we explore how to use the <fieldset> and <legend> elements to group and label form elements effectively, creating a more accessible and well-structured experience.

Meet Andre, a music producer and blind screen reader user who is not afraid to take his custom elsewhere if your site is not accessible.

Andre shares his experience using the web including his love of headings and consistent design to help him navigate, and his dislike of accessibility overlays and poorly implemented page updates using live regions.

As well as labelling text fields with input and labels, and grouping forms with the <fieldset> and <legend> elements, form validation and error messages are also essential to making forms accessible to everyone.

Meet Hasmukh, a talented blind cricketer with lots of patience and determination.

Hasmukh shares his experience using the web with a screen reader and highlights the importance of accessible emails, forms, language, and prioritising content within a web page.

In this post about forms, we explore how to effectively label text fields using <input> and <label> elements to create form inputs that are both accessible and user-friendly.

Live regions have a reputation for being "flaky" and inconsistent. While this can be attributed in part to shortcomings in current implementations, the problem can also be caused by developers misunderstanding how live regions are intended to work.

When tabindex="0" is applied to an HTML element, the content marked up using that element will become keyboard focusable, and is therefore a good starting point for supporting keyboard accessibility. However, applying this attribute haphazardly or unnecessarily can reduce the experience for people who use a keyboard or an equivalent input device to navigate web content.

Like many inventions before it, Generative AI is changing the way we do things. Like those inventions that went before it, Generative AI is capable of great good and great harm, and like the humans that used those inventions before us, we need to be smart about the way we use Generative AI.

An element's name, or accessible name, is how it's identified. An accessible description provides additional information, about the element, that complements the accessible name.

In this post we explore assigning accessible names and descriptions using HTML and WAI-ARIA.

The Web Accessibility Initiative Accessible Rich Internet Applications specification 1.2, or WAI-ARIA or ARIA for short, is a technical specification written by the World Wide Web Consortium (W3C).

In this post we explore what WAI-ARIA is, and how it can enhance the user experience for people using screen readers.

Deciding whether to use native or custom components for a website or web application can have implications in terms of development effort, user experience, and accessibility. This post considers the pros and cons of each approach with a focus on accessibility, and provides guidance on how to choose one.

HTML semantics provide accessibility information about page structure and an element's role, name, and state, helping to convey the nature and purpose of content on web pages.

In this post we explore what HTML semantics are, and how they're experienced by people using assistive technologies like screen readers and speech recognition software.

Given that Internet Explorer 11 is now officially retired, organisations occasionally ask us if, from an accessibility perspective, they should continue to support the browser. In short, we're edging (no pun intended) towards dropping support, or at least phasing out support, in favour of Microsoft Edge. There are a few reasons for this, both technical and non-technical.

TalkBack only announces role information for a relatively small number of user interface (UI) elements within native apps. When comparing this behaviour against web content, this can often give the (false) impression that these elements must have been coded incorrectly and therefore need to be "fixed".

This blog post looks at when it is acceptable for a role not to be announced, the roles that TalkBack does announce, and what this means for conformance to the Web Content Accessibility Guidelines (WCAG).

A list is generally agreed to be a series of words or phrases that are grouped together for a reason. That reason might be to remember the items we want from the store, to share our top five favourite movies, or to write down the steps needed to complete a task.

Most websites have common areas of content like a header and footer, a main content area, and one or more navigation blocks. Sighted people can identify these areas based on the way they're styled and the content they contain, but people who are blind cannot do that quite as efficiently. Landmarks, like headings and lists, offer screen reader users a more comparable experience for identifying and navigating between different areas of content.

Session timeouts are designed to protect privacy and security, but if they’re implemented incorrectly, they can prevent people from completing tasks on a website.

Well structured content helps everybody understand and navigate documents. When coded properly in the HTML, headings, lists, and landmarks help people who use screen readers (software that reads what’s on screen) both scan and navigate pages.

Text descriptions are primary content, and when images do not have a text description, anyone who cannot see the image will not know its purpose. This means people may be unable to access content or perform related tasks.

Understanding how people with disabilities browse the web using assistive technologies (AT) is core to making an accessible and inclusive user experience. Our browsing with assistive technology videos series introduces commonly used software, who uses it, how it works, and ways people navigate content.

In our fifth and final post from our browsing with assistive technology series, we discuss browsing with speech recognition.

You can also explore browsing with a desktop screen reader, browsing with a mobile screen reader, browsing with a keyboard, and browsing with screen magnification.

In our fourth post from our browsing with assistive technology series, we discuss browsing with screen magnification.

You can also explore browsing with a desktop screen reader, browsing with a mobile screen reader, browsing with a keyboard, and browsing with speech recognition.

In our third post from our browsing with assistive technology series, we discuss browsing with a keyboard.

You can also explore browsing with a desktop screen reader, browsing with a mobile screen reader, browsing with screen magnification and browsing with speech recognition.