People we are designing for

In any form, anxiety, which is the body's response to a perceived threat, can be disruptive, overwhelming, and deeply uncomfortable. In a typical threat response, the surge of stress hormones such as cortisol and adrenaline subsides once the danger passes. But with anxiety, the “threat” is often internal; a worry, fear, or sense of uncertainty that doesn’t resolve cleanly. The body stays on high alert, and the stress response doesn’t switch off. This can leave people in a heightened state of arousal, with reduced cognitive bandwidth and fewer mental resources available for processing information, making decisions, or staying focused.

Like most human experiences, anxiety exists on a spectrum. For some, it can be debilitating, for others, it’s a persistent background noise. Understanding the different types of disability helps designers recognise why these variations matter.

Considerations

These considerations focus on reducing cognitive load, lowering stress, and creating experiences that feel calmer and clearer for everyone. It’s not a complete list, but it highlights the areas that make the biggest difference to a calmer, more supportive user experience. We also recognise that while the Web Content Accessibility Guidelines (WCAG) offer a foundation when designing for people with anxiety, they provide only partial support. We want to ensure we look beyond basic compliance when designing for people with disabilities and consider the more thoughtful, human-centred steps we can take in our design.

Give people time

It’s common for websites to place people under time pressure with visual countdowns. While timers alone can create anxiety, they can be especially overwhelming for people who are already stressed or feeling rushed. For many, that ticking clock is enough to prompt them to abandon the task entirely, or to hurry through steps and make decisions they’re not comfortable with. Ticketing websites and Two-factor authentication (2FA) flows are well-known examples: session timeouts require people to act within strict time limits, regardless of how ready or at ease they feel.

WCAG speaks directly to this issue in Success Criterion 2.2.1: Timing Adjustable, which states that people must be able to do at least one of the following:

• Turn off the timer
• Adjust the timer
• Extend the timer
• Or have a timer set for over 20 hours

There are exceptions, such as real-time events or essential processes. Ticketing sites often fall into these categories, but even then, strict timers can cause significant discomfort and increase abandonment rates. In short, time pressure can be deeply destabilising. Wherever possible, avoid countdowns, or provide people with meaningful control over them to ensure time limits don’t heighten anxiety or prevent people from completing important tasks.

If you have to use time-dependent interactions, consider implementing the following:

• Be generous with time: consider extending the time for the 2FA code and the count down for the ticket-purchase flows to give people more flexibility
• Offer the option to hide the countdown: even with ample time, the presence of a ticking timer can be stressful; allow people to hide the visible countdown, replacing it with gentler prompts such as “Your session is about to expire, request more time if needed”
• Use kind, supportive copy: reassuring language helps reduce stress; phrases like “Take your time” or “If your code expires, you can request a new one here” can make the experience feel calmer and more accommodating

This approach aligns with one of the seven inclusive design principles: give control, which emphasises that people should remain in control of their experience, and our designs should actively support that.

Ensure people are in control. People should be able to access and interact with content in their preferred way.

Limit the urgency

Limit urgency wherever possible. Many retail and booking sites introduce UI elements that amplify a sense of pressure. Similar to countdowns, these cues can have a negative effect on people, especially those who are anxious, by prompting them to abandon the process or make decisions they don’t feel ready for.

For example, some shopping sites use scarcity cues by highlighting how many people have an item in their cart. Another technique is to display how popular an item is or how many offers it has received (on a bidding website). Although this information can be useful, it can also feel manipulative and create unnecessary stress. For people who experience anxiety, these urgency cues can rush them into decisions or push them away entirely, without giving them the space they need to think comfortably.

This aligns with the Inclusive Design Principle of consider situation, but ironically in reverse. In practice, many products and services exploit these situations to drive faster decisions, which makes the experience less supportive and less inclusive.

People use your interface in different situations. Make sure your interface delivers a valuable experience to people regardless of their circumstances.

Keep interactions predictable

Predictable and familiar designs may not eliminate anxiety, but they won’t heighten it. People feel more at ease when interfaces conform to established patterns and follow expectations.

A common problem is when a pop-up takes over the entire screen but doesn’t behave as expected. The close button might appear late, be hard to see, be placed somewhere unusual, or be missing entirely. Sometimes the only way to dismiss the pop-up is to wait, click outside it, or interact with the unwanted content.

A related issue is the use of interactive elements styled to look like plain text. For example, a cookie banner from a retail site that occupies a third of the screen with a prominent “Accept All” button, while the “Cookie settings” option appeared as un-styled text. Because it didn’t look clickable, people may assume they have no real choice other than to "Accept All". Such unexpected behaviour can increase stress, break focus, and make the experience feel less under the individual's control. It also prompts an immediate distrust of the page.

As such, keep interactions predictable by using recognisable UI conventions. For example, ensure close buttons in pop-ups and dialogs are clearly visible, focusable, and placed in the expected top-right position.

As well as aligning with give control from the Inclusive Design Principles, it also aligns with be consistent, a principle that highlights the importance of using familiar conventions so that people can navigate with confidence, relying on what they already know rather than being forced to learn novel patterns.

Use familiar conventions and apply them consistently.

Provide clear progress updates

If we consider anxiety comes from uncertainty, one way to reduce it is by providing as much transparency as possible. In multi-step journeys, progress indicators are an effective way to communicate this transparency. They can show how many steps are involved and clearly highlight the current position in the process. It’s important that these indicators are accessible to everyone, including people who rely on visual indicators and people who use screen readers.

The goal is to create cohesive and transparent experiences that give people the information they need without overwhelming them. Providing this clarity can reduce stress, help people stay focused, and even allows them to make informed decisions, such as whether they have the time and capacity to complete a task now or should return to it later. Without this insight, people may abandon the process because they can’t judge how long it will take.

Be transparent when requesting information

It’s important to explain why certain information is being requested. If someone in real life asked for your date of birth or your pronouns without context, both personal details that aren’t automatically assumed, you might feel cautious or hesitant. Forms work the same way. Offering a brief explanation reduces worry, builds trust, and reassures people that their information is being requested for a clear, legitimate purpose.

Equally, if you can't find a significant or convincing reason as to why you are asking for certain information, consider not asking it. This small moment of transparency can prevent already anxious people from spiralling into further anxiety about where their data is going or why it’s needed.

Some forms require people to have specific documents or information in order to complete them, such as proof of address or a passport. Providing people with instructions before they start a form is a simple and effective way to help them feel more prepared and in control as shown on the following Gov.uk example.

This transparency empowers people by setting clear expectations and giving them time to prepare, rather than leaving them feeling caught off guard, something that can be compounded when faced with a form time out and a need to retrieve something to finalise the form.

Give options to review

It’s important to give people the opportunity to review what they’re doing, whether that’s checking their answers in a form or confirming the details of an order. Wherever possible, avoid allowing people to submit something without a chance to review it first.

A good example is the card design process on an online service where people create custom cards that are sent directly to the recipient. Since the final product goes straight to someone else, it’s especially important that people can clearly see what their design will look like before submitting it. By providing a prominent “Preview” button you give people greater confidence and clarity, helping ensure they feel certain about what they’re sending.

Implement accessible wayfinding

Anxiety often increases the desire for control, so it’s important to assume that people want to know where they are within a complex website or process, and have the ability to orient themselves easily. Accessible wayfinding helps people understand their current location, the options available to them, and how to navigate to their next step.

The type of wayfinding you use depends on the depth and complexity of your website or application. While not all approaches are necessary, several can be highly beneficial.

Breadcrumbs

A series of links that show people their location within a website’s hierarchy and allow them to navigate between levels. Often used when there is a deep hierarchy. Typically, the last item represents the current page, though it may sometimes be omitted.

Navigation

Usually presented as a horizontal or vertical set of links, navigation helps people understand the main sections of a website and move between them with ease.

Search functionality

On large, complex websites, such as retail or news sites, search allows people to quickly locate specific content by entering keywords and filtering results. It provides a fast, direct path to the information needed

Resources

• A web of anxiety: accessibility for people with anxiety and panic disorders, Part 1 - TPGI
• A web of anxiety: accessibility for people with anxiety and panic disorders, Part 2 - TPGI
• The architecture of anxiety and shame - Todd Libby
• Guide to the Inclusive Design Principles
• Designing for users with anxiety PDF - UK Home Office

Next steps

For more information about the Web Content Accessibility Guidelines, read our WCAG primer or find out more about how our assessments can help you identify issues in your websites, mobile applications, design systems, and other products and services.

Regardless of your role, whether you are a content, visual, interaction, or user experience designer, your job is to create meaningful experiences for everyone, including people with different types of disabilities. This applies to all kinds of interface, from websites and apps to kiosks, extended reality (XR), smart TV interfaces, voice interfaces, and wearables.

Meeting the Web Content Accessibility Guidelines (WCAG) is part of that responsibility, but not all of it. After all, it’s people who use your product, not guidelines.

Here are a few considerations to underpin your design process and support more intentional, inclusive design.

Design for people not standards

Starting with people changes the kinds of decisions teams make. Inclusive design is not just about implementing requirements correctly, but about shaping outcomes that work for how people think, move, see, hear, and process information in real contexts.

WCAG provides the foundations, but compliance alone cannot define good design. Interfaces are used by different people, in different ways, and in different situations, and no set of guidelines can account for all of that complexity.

One way to broaden design thinking is to use the Inclusive Design Principles. These are not a set of requirements to comply with. Instead, they help teams clarify design intent and think through decisions that sit outside implementation guidance. WCAG focuses on how to implement things like colour contrast, text alternatives, and keyboard access. The Inclusive Design Principles focus on what to design in the first place, from choosing appropriate features to shaping user journeys and interactions around real people’s needs.

For example, WCAG can tell you how to make a complex multistep form accessible. Design intent asks whether that complexity is necessary at all, whether steps can be reduced, or whether the task should be supported differently.

Recognise that disability is not a set of edge cases

There are no absolutes in human experience. This is true across different types of disabilities, and even more so in how people interact with products and services.

What works well for one person may be confusing, tiring, or frustrating for another. Disabilities vary not only by type, but by severity, context, environment, and circumstance, all of which shape how someone experiences an interface at a given moment.

Take Steve, a London-based photographer who is both deaf and has low vision. His experience is different from someone who is only deaf or only has low vision. Having multiple disabilities shapes how he perceives and navigates the world, and how he interacts with digital products using particular combinations of assistive technology and adaptive strategies.

For Steve, design decisions that reduce reliance on hearing or fine visual detail can make a significant difference. Using the example of a multistep form again, clear visual feedback, predictable progression, and instructions support easy completion. By contrast, forms that depend on subtle visual cues, low-contrast overlays, or toasts can quickly become frustrating or inaccessible.

These design choices benefit everyone. They improve clarity and usability for everyone, not only people with disabilities.

Use design considerations that support multiple disabilities

The good news is that while disability is not a fixed or uniform experience, many needs overlap. As such, design considerations that work for someone with low vision, can also work for someone with reading disabilities or who is colour blind.

Here are just a few design considerations that support multiple types of disability:

• Clear and predictable journeys: user flows that make it obvious works for people who are blind as much as they do for people with cognitive disabilities or anxiety
• Meaningful feedback: confirming that an action has succeeded, failed, or is still in progress helps people with low vision, cognition, or reading disabilities who may miss subtle changes or audio cues
• Easy error prevention and correction: making it easy to avoid, correct, or recover from errors benefits people who may struggle with precision, focus, or confidence, including people who rely on a keyboard or don't use a mouse, as well as people who have cognitive or reading disabilities

Designing inclusively is also a form of future-proofing. Situational and temporary disabilities affect all of us at some point, whether it’s using a phone in bright sunlight, typing one-handed while holding a baby, using a mouse with an injured hand, or trying to complete a form when tired.

Include people with disabilities in the design process

There is no substitute for feedback from real people. WCAG assessments are essential for identifying technical accessibility issues, but they cannot show how an experience actually feels to use. Only people can tell you where something is confusing, exhausting, anxiety-inducing, or difficult to use.

Involving people with disabilities early and throughout the design process surfaces barriers that automated tools and compliance checks will never detect, such as unclear journeys, misleading feedback, or interactions that technically pass but are hard to use in practice.

Our inclusive user research series explores how to do this well with guidance on:

• Recruiting participants
• Building rapport
• Moderating sessions
• Analysing findings

Build accessibility into the design process

Accessibility fails most often when it is treated as something to fix later. When it is built into the design process from the start, teams make better decisions earlier, avoid rework, and reduce the risk of shipping experiences that technically pass but are hard to use.

Embedding accessibility from planning through research, design, and delivery makes it part of how work gets done, not an extra step at the end. Accessible design systems play a key role here by locking in inclusive decisions, reducing duplication, and making accessible patterns the default rather than the exception.

Building accessibility into the design process saves time and cost over the long term, but just as importantly, it builds a culture of accessibility where inclusive design is expected, understood, and sustained.

Next steps

Find out more about usability testing at TetraLogical and how people with disabilities browsing the web using assistive technologies experience the web.

Our Accessible building blocks for web video series introduces key accessibility considerations for some of the most widely used elements on websites - from headings to images, links, buttons, and form fields.

Three key aspects that impact the accessibility of web elements are language, visual design, and implementation. Each video in the series shows how to apply clear language, inclusive visual design, and accessible coding to each of the building blocks.

We created these videos following an inclusive approach to video production, so they are accessible to all.

You can view the videos below or on the accessible building blocks for web playlist on YouTube. You can also access the accessible building blocks for web with British Sign Language (BSL) playlist on YouTube.

Headings

Learn how to create headings that are easy to understand and identify for everyone, and make sense to people using screen readers.

Images

It's important that the information in your images is available to everyone, including people who cannot see them and use a screen reader, people who enlarge them, and people who view them in bright sunshine.

Links

Discover how to write and design links that are easy to understand, identify, and select for all; and how to code them so they work with all input devices.

Buttons

Ensure the buttons on your website are accessible to everyone by giving them a descriptive label and an appropriate visual appearance, and by including all necessary information on their functionality in the code.

Form fields

Apply key accessibility considerations when designing and implementing form fields - from clear labels and error messages, to good label positioning and inclusive use of colour, to appropriately associated html elements.

Next steps

If you enjoyed these videos, why not explore our other video series:

• Quick accessibility tests anyone can do
• Browsing with assistive technology

Or head to embedded accessibility to learn how we can help you achieve sustainable accessibility.

Covering a range of topics from disabilities and assistive technology to implementation practices and testing tools, these posts are for anyone who wants to better understand how to build products that work for everyone.

Common misconceptions about disability

With around 1.3 billion people in the world recognised as having a disability and many more experiencing temporary and situational disabilities, we are all likely to benefit from accessible products.

Explore the types of disabilities that can impact people's experience on the web, how we should think and talk about people with disabilities, and the benefits of offering inclusive products.

Common misconceptions about screen readers

Many people working in digital would have heard of screen readers but not all may know how they work and who uses them and how.

Discover what you should and shouldn't do when building products to ensure they work well for people using screen readers.

Common misconceptions about WCAG

The Web Content Accessibility Guidelines (WCAG) have been regarded as the international standards for web accessibility for over 20 years. Everyone working in digital should be familiar with its requirements and know how to meet them. However, there often still is confusion about what WCAG covers and how it should be used.

Explore some common misconceptions about WCAG, including what products it applies to, and what conformance level you should aim for.

Common misconceptions about implementing accessibility

What are the best tools and practices to use to build truly accessible products? And how to make sure your products remain accessible overtime?

These questions are answered while while unveiling common misconceptions about AI tools, obverlays, and design systems.

Common misconceptions about testing accessibility

With so many tools and methodologies available, it can be hard to know where to start when it comes to testing accessibility.

Explore who is responsible for accessibility testing and what the best approach is.

Next steps

Find out more about Sustainable Accessibility and how we can help your organisation achieve long-term accessibility, or our Assessments to learn how we can help your organisation validate the accessibility of your products.

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

With so many testing tools and methodologies available, it's not easy to know what the most effective approach for testing the accessibility of your products is. We look at some of these misconceptions and how to address them.

Misconception 1: I can rely on automated testing tools

You may have come across automated tools that promise to test and identify all accessibility issues within your website or app. It can be tempting to rely solely on these tools when testing for accessibility. However, no automated tool can truly test all aspects of accessibility, no matter how expensive or advanced the tool is. The most they can test for is between 20% and 40% of accessibility requirements from the Web Content Accessibility Guidelines (WCAG).

Accessibility is more than just accessible code

Automated tools mainly focus on the code behind websites and apps. As explained in common misconceptions about WCAG, accessibility is much more than accessible code. It's good visual design, inclusive multimedia, well-crafted editorial, inclusive language and more. Many of these are missed by automated tools.

Human judgment is still required

Many accessibility tests cannot be performed by automated tools as they require human judgment. For example, can generative AI write contextual text descriptions and how can a tool judge whether an error message is clear and provides useful suggestions?

Automated testing tools can help you quickly identify some common issues with your website or app code. However, you shouldn't rely on them alone; use them in conjunction with other testing methods, such as manual testing and usability testing with disabled participants.

Misconception 2: it should be done at the end of development

In some organisations, accessibility testing is the sole responsibility of QA testers and it happens at the end of a product or feature development process. Issues identified this late can be difficult and costly to fix.

As covered in common misconceptions about implementing accessibility, everyone working on a digital product is responsible for its accessibility. This includes testing against accessibility requirements at each stage of development. For example, designers should check the accessibility of their designs before sharing them with the development team; media producers and content writers should do the same with the content they create; and so on.

When everyone plays their role in both following accessibility guidelines and carrying out basic testing, products should present fewer issues when they reach QA.

Testing accessibility as early as possible and at every stage of development is key to delivering accessible products.

Misconception 3: only accessibility specialists can do testing

For people new to accessibility, testing may seem a challenging and at times overwhelming. They may therefore assume that only accessibility specialists can and should do it. This isn't the case.

As mentioned above, everyone working in digital teams are responsible for the accessibility of products and should be able to perform some basic testing. You don't have to know all about accessibility; you should focus on those aspects of accessibility relevant to your role. Content writers, media producers, designers, and developers should all conduct a separate, specific set of tests.

At times, you may need the advice and expertise of an accessibility specialist, especially when working on a complex or innovative component, for example. However, most of the day-to-day testing can be performed in-house.

Ensure that people working in digital within your organisation have the training and tools required to perform accessibility testing. This will make it an integral part of everyone's job and will reduce your reliance on accessibility specialists.

Misconception 4: I should test across all Operating Systems (OS), browsers, and Assistive Technologies (AT)

Digital products can be accessed across many operating systems and browsers, using different types of assistive technology and adaptive strategies, input devices, and built-in accessibility features. This often leads teams to assume they need to test across every possible device and combination.

Thankfully this is not the case. That would require a huge amount of time and money.

As long as products comply with accessibility standards and best practices, such as the Web Content Accessibility Guidelines (WCAG) and the Inclusive Design Principles, they will work well across devices and with all technology. While you may decide to test some content, such as non-standard components, with a wide range of OSs, browsers, and ATs, this is generally not the norm.

When testing your products, focus on the most commonly used devices, browsers, and ATs. The WebAIM Screen Reader User Survey is a good place to find out about screen reader usage.

Misconception 5: I can just ask people with disabilities for their feedback

Watching people using a product is a great way to identify accessibility and usability issue. Agile Usability Testing gives teams an opportunity to place their products in front of people with a range of disabilities and get valuable insights.

There may also be people with disabilities in your team or across your organisation who you can reach out to for quick feedback.

However, relying on people's feedback alone is generally not a good approach.

People are unique

We are all unique. Each of us, either with or without a disability, have our own needs and preferences, and use digital products in different ways. For example, not all people use screen readers in the same way.

As discussed in our inclusive user research: analysing findings post, when running user research with people with disabilities we often end up with quite different and, at times, contrasting feedback from different people. If you're not an expert in accessibility, you may easily mistake personal preferences or opinions for accessibility issues. For example, a person new to their screen reader may struggle navigating tables as they are still unfamiliar with table navigation keys; this doesn't mean there is a problem with the tables.

Some requirements may be missed

Unless you have access to a very large panel, there is a good chance you won't be testing all accessibility requirements. For example, Success Criterion 1.4.10 Reflow from WCAG requires that:

Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for:

• Vertical scrolling content at a width equivalent to 320 CSS pixels;
• Horizontal scrolling content at a height equivalent to 256 CSS pixels.

Unless you happen to have a person in your panel that enlarges the content and uses the settings listed in this Success Criterion, you won't be able to test this specific requirement.

Running formal or informal user research is hugely valuable and allows you to uncover practical accessibility and usability issues. However, on its own, it cannot replace thorough accessibility testing. As mentioned under Misconception 1 above, you should run it in combination with other testing methods, such as automated testing and manual assessments.

Next steps

Head to Assessments to find out how we can help your organisation validate the accessibility of your products, or learn how our Agile Usability Testing and User Research Mentoring services can assist you with running user research with people with disabilities.

Misconceptions about how to implement accessibility are common, whether it’s overreliance on AI tools and overlays, the assumption that accessibility is only a developer’s job, or uncertainty about how to use design systems and component libraries effectively.

Here we discuss some of these misconceptions and provide advice on how to implement true and sustainable accessibility.

Misconception 1: it’s only developers’ responsibility

Some people expect accessibility to happen entirely at the coding stage; developers do their magic, and here you are with your shiny, fully accessible website or app. That's far from reality.

As discussed in our common misconceptions about WCAG, accessibility is much more than just accessible code; it's good visual design, inclusive multimedia, well-crafted editorial, inclusive language and more. Everyone involved in planning, designing, and building a digital product is responsible for its accessibility.

While developers do play an important role in implementing accessibility, they cannot turn inaccessible designs or content into an accessible product. For example, a design containing poorly contrasting colours cannot be made accessible at the development stage. Also, developers shouldn’t be responsible for writing text descriptions for images; the person selecting the images is best placed to do this, as they better understand the context in which the images are used.

Accessibility shouldn’t fall solely on developers; it's a team effort!

Misconception 2: I can rely on AI tools

With so many AI enabled tools available and vibe coding becoming more and more popular, it may be tempting to assume we can rely on them to generate accessible content. However, this is not the case.

While AI can help write code, when it comes to accessibility they present two major drawbacks:

• They are trained on inaccessible code: we know that much of the existing code is inaccessible, and code generated by AI often includes the same mistakes
• They lack a holistic approach: even when AI generates accessible code, that on its own is not enough to build accessible products (as discussed under Misconception 1 above)

We put some AI tools to the test and asked them to write some text descriptions and lines of code. Many of the results we got were incorrect or inaccurate. If you want to learn more about it, head to our can generative AI help write accessible code? and can generative AI write contextual text descriptions? blog posts.

If you use AI to help you write code, always double check it complies with accessibility requirements. And don't solely rely on the accessibility information provided by AI, always verify what AI gives you against reliable sources.

Misconception 3: I can simply use an overlay

Some organisations choose to use "accessibility overlays" as a quick and easy solution to achieve accessibility.

Accessibility overlays are third-party tools that can be added to a website with the aim to enhance its accessibility. In addition to providing a variety of tools and customisation options to the people using the website, they claim they can identify and fix accessibility issues in the website code.

As explained in the Overlay Fact Sheet, this is not technically achievable. Many accessibility issues require manual rectification. For example, colours with insufficient contrast, images with missing or inaccurate text descriptions, text that is not identified as a heading, unclear error messages...the list goes on. This is why between January and June 2025 alone, in the USA 456 ADA lawsuits were filed against websites that use accessibility widgets and overlays.

Also, these tools often end up interfering with the assistive technologies, input devices, and accessibility features used by many people, resulting in a worse, rather than improved, user experience. Here is a quote from a blind person, taken from the Overlay Fact Sheet:

...I know with 100% certainty, any site which has deployed an overlay in the past year and a half has been less useable for both my wife and me - both blind.

Don't be tempted to use a tool that promises to automatically fix all the accessibility issues on your website. True accessibility requires proper planning and implementation at every stage of a product's development process.

Misconception 4: accessibility stops at launch

It's not uncommon to see digital teams doing an amazing work at implementing accessibility while developing a website or app but then stop worrying about accessibility once the product is launched. This often results in accessibility issues starting to appear in just a few months.

Websites and apps are living creatures; they are constantly updated and modified. Any change, small or large, can introduce accessibility issues. This is why accessibility needs to be properly planned and maintained over time.

A few actions you can take include:

• Ensuring that accessibility is an integral part of all the processes and documentation used in your organisation
• Including accessibility requirements in design systems and component libraries used by designers and developers
• Providing everyone working in digital with the training and knowledge they need to implement accessibility

You can find more practical suggestions on how to embed sustainable accessibility into your organisation in our guide to sustainable accessibility.

Misconception 5: I just need to use accessible style guides and components

Nowadays, most organisations have design systems and component libraries which provide designers and developers with style guides and reusable components, thus ensuring consistency across websites and apps. More and more of these have accessibility integrated. This means that when a style or component is used, it already includes key accessibility features. For example, a button may present a large target size area and a good contrasting border, and be coded with the correct HTML elements so it is keyboard and screen reader accessible. This is an important first step into building accessible content but on its own is not enough.

Re-using accessible styles or components alone is not enough. Accessibility also needs to be considered when combining components into web pages or app screens. For example, you need to ensure that:

• Components follow a logical visual and reading order
• Heading levels convey the correct content structure
• When leaving a component, the keyboard focus moves to the most logical location on screen

Ensure that you and your colleagues have the knowledge and skills you need to know how to best use and combine your organisation's style guides and components so you can create accessible content.

Next steps

Learn how our Sustainable Accessibility and Training services can help your organisation implement and maintain accessibility in the long term.

WCAG is recognised internationally as the standard for digital accessibility. They are often mentioned in organisations’ accessibility policies and referenced in many laws and regulations worldwide. Our WCAG primer provides an overview of the guidelines and how they’re structured.

In this post, we look at some of the most common misconceptions about WCAG and explain how they fit into everyday design, content, and development decisions.

Misconception 1: WCAG only applies to websites

When the very first version of the guidelines (WCAG 1.0) was published in 1999, the internet was largely synonymous with websites. As a result, the guidelines were pretty much focused on web content built with HTML.

This is no longer the case. The current version of the guidelines, WCAG 2.2, is applied to all digital content from websites to web applications, native apps, and digital documents. While some techniques in WCAG may refer to a specific technology (HTML, ARIA, PDF and so on), the principles, guidelines, and Success Criteria (SC) are technology-agnostic.

Let's take a look at the very first SC in WCAG 1.1.1 Non-text Content:

All non-text content that is presented to the user has a text alternative that serves the equivalent purpose [...]

This applies to all forms of digital visual content, from photos on websites to infographics in PDFs and icons in native apps.

Regardless of the type of digital product or technology you work on, you can and should apply WCAG to it.

Misconception 2: WCAG is only about screen readers

When thinking about accessibility, some people assume it's all about screen readers.

Screen readers are one of the most well-known assistive technologies out there. They help many people, including people who are blind, have low vision, and some people with thinking disabilities, access web content. You can see some screen readers in action in our browsing with a desktop screen reader and browsing with a mobile screen reader blog posts.

Some SC in WCAG 2.2 focus on coding practices that make digital content work well with screen readers and other assistive technology. But WCAG go far beyond screen reader support. The SC cover a wide range of accessibility needs, including visual design, media content, clear language, and keyboard access.

This means that applying WCAG is relevant to everyone in a digital team, including content writers, UX and UI designers, and media producers.

Misconception 3: WCAG-compliant websites and apps are "basic"

As WCAG contains requirements around the use of colour, images, and multimedia content, some people believe accessible websites and apps must have a flat black-and-white text only design, with minimal use of images, multimedia, and a basic layout.

But minimalist websites and apps can actually be inaccessible for some people. Images and multimedia content are an important aspect of accessible products, as they can make information easier to understand for some people with thinking disabilities. Colour can also help reinforce meaning and help people identify items such as headings and links, as well as understand information.

Accessibility is not about removing elements that may be inaccessible to some, it's about using them in an inclusive way and providing alternatives when necessary.

On the TetraLogical website, we use bold colours, plenty of images, and our homepage even includes an animation. However, we make sure that people accessing the website can customise their experience to best suit their needs and preferences. For example, a Pause button allows people to pause the homepage animation, and our content adjusts as expected when people change colours and font sizes in their settings.

WCAG-compliant websites don't need to be "basic". They need to be adaptable.

Misconception 4: WCAG compliance requires meeting all Success Criteria

WCAG 2.2 contains 86 Success Criteria, each assigned to one of three conformance levels:

• Level A: the minimum set of requirements needed for basic accessibility
• Level AA: addresses the biggest and most common accessibility barriers
• Level AAA: the highest level of accessibility

You may think your products should meet all 86 SC. This is not the case.

Most organisations should aim to achieve Level AA compliance. This means complying with 69 SC. By meeting Level AA compliance, your products will be accessible to most people with disabilities.

Level AAA SC cover more advanced requirements, to address the needs of specific groups of disabled people. Only organisations offering products or services specifically to those groups of people are required to implement them.

For example, SC 1.2.6 Sign Language (Prerecorded) requires that:

Sign language interpretation is provided for all prerecorded audio content in synchronized media.

Providing sign language interpretation for video content greatly benefits Deaf people whose first language is sign language. Organisations whose main target audience includes Deaf people should make sure all their video content offers sign language interpretation. Other organisations are encouraged to do the same when feasible; however, in some cases it may be too costly or not achievable.

As stated in WCAG 2.2:

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.

Focus on achieving Level AA conformance across your products and services first. You can then look into Level AAA to identify those additional requirements you can implement to further improve your products. You can learn more about Level AAA in understanding WCAG 2.1 Level AAA.

Misconception 5: WCAG compliance means products are easy to use

WCAG covers a wide range of requirements that will help you reach technical accessibility. For example, WCAG-compliant products support keyboard access and work well with screen readers and other assistive technology; they use colour combinations that meet a minimum contrast ratio; provide alternatives for images and multimedia content; and so on.

This is all key to inclusive products, but it's only an aspect of it. To be truly inclusive, websites and apps must make it easy for everybody to:

• Find the information they need
• Read and understand the information
• Understand how to complete tasks
• Go through journeys

Applying WCAG together with usability and inclusion best practices, such as the Inclusive Design Principles, will allow you to build truly inclusive products.

Conducting inclusive usability testing is also key to ensuring your websites and apps are easy and enjoyable for everyone to use.

Next steps

Find out how our assessments can help you validate your products' conformance with the Web Content Accessibility Guidelines (WCAG), or learn how our Sustainable Accessibility service can help your organisation reach accessibility in the long term.

According to the World Health Organisation, around 1.3 billion people – or 16% of the global population – experience a significant disability. This number continues to grow.

Types of disability can vary greatly from person to person, and the barriers people face can depend as much on other people’s perceptions and attitudes as on their environment or condition.

Misconception 1: all disabilities are visible

Many people assume that disability can always be seen. In reality, this is far from true. Someone may need a wheelchair to navigate one day but be able to walk the next, as in the case of chronic fatigue. Others may experience pain, neurological, or cognitive conditions that have no visible markers at all.

That’s why accessible facilities such as toilets and priority seating on public transport often carry the message “not all disabilities are visible”; a reminder that we cannot know someone’s circumstances or needs from a visual inspection.

In the UK, the Hidden Disabilities Sunflower scheme helps people indicate that they have an invisible disability, encouraging inclusivity, acceptance, and understanding in the general population. It also has a non-visible disabilities index with details of commonly missed disabilities, how they might affect people, and assistance and support you may be able to offer.

Misconception 2: all disabilities are permanent

Disability is not always a lifelong condition. According to research from the Institute for Public Policy Research (PDF), only 17% of people with a disability were born with it; the rest acquire it during their lifetime.

A disability can be permanent, temporary, or situational, and these categories often overlap.

• Permanent disabilities are long-term conditions that are not expected to change and may require consistent adaptations or support, such as being Deaf or having no upper body movement
• Temporary disabilities are non-permanent conditions or injuries that affect someone for a limited time, such as a broken bone or an ear infection
• Situational disabilities are a temporary inability to complete a task, caused by a specific context or environment, for example being in a noisy environment where it’s difficult to hear or being in bright sunlight where it is difficult to see a screen

If you’ve ever broken an arm, carried a baby, or been unable to read your screen in bright sunlight, you’ve experienced a form of temporary or situational disability. This shows how accessibility benefits everyone, not just people with permanent disabilities or health conditions.

These types of disabilities can overlap, meaning a person may experience more than one at the same time. For example, a blind person using a screen reader in a noisy environment with broken headphones would be experiencing a combination of permanent and situational disabilities.

It’s impossible to design for every single user experience, which is why it’s best practice to make your website or service accessible and user-friendly as possible for a wide range of people.

Misconception 3: accessibility features are only for people with disabilities

Accessibility features are often developed with disabled people in mind, but they can end up improving usability and convenience for everyone.

Captions, for example, were originally designed for D/deaf and hard-of-hearing viewers by displaying a text version of a video’s dialogue and key sounds. Today, captions are widely used by people learning new languages or people watching in either noisy or quiet environments where sound isn’t practical.

Research shows just how broad their appeal is: Verizon Media and Publicis Media found that around 85% of videos on social media are watched without sound, and 80% of viewers are more likely to watch an entire video when captions are available. Captions improve comprehension and engagement for everyone.

The same is true of many other accessibility features found in your device settings. Tools such as pinch-to-zoom, high-contrast mode, voice input, and digital assistants like Siri or Google Assistant were built to support specific access needs. Today, millions of people use various assistive technology and adaptive strategies daily because they make digital experiences more comfortable, efficient, and adaptable.

Misconception 4: people with disabilities should be seen as heroes

It’s common for well-intentioned people to describe someone with a disability as “inspirational” or “brave”. While meant as a compliment, this kind of praise treats disability as something extraordinary that must be constantly overcome. It can feel patronising, reducing people to a medical diagnosis, rather than recognising them as individuals.

For most people with disabilities, this is simply part of everyday life, and just one aspect of who they are. Often, the biggest challenges are not people's impairments, but the barriers and attitudes they encounter, such as inaccessible buildings, intrusive questions, or inaccessible digital products and services that exclude them.

People with disabilities also lead rich, varied lives that have nothing to do with disability. Read our blog post series "Meet the models", starting with Jonathan, a photographer who has ADHD to find out more about an inclusive photoshoot we ran with five people focused on their personalities, skills, and hobbies, rather than just their disability.

Misconception 5: disability inclusion is only a social issue

Accessibility and inclusion are often seen purely as ethical or compliance matters, but they’re also smart business decisions. People with disabilities represent a significant share of the global market, and organisations that fail to consider accessibility are turning away customers, employees, and opportunities.

The term "The Purple Pound" refers to the spending power of disabled households where at least one member has a disability. According to We Are Purple, more than one in five potential UK consumers has a disability. Businesses lose an estimated £2 billion every month by ignoring the needs of disabled people, and the online spending power of this group is estimated at over £16 billion.

People with disabilities are hugely influential in the workplace and contribute to the workforce of most, if not all, industries. There were 5.5 million disabled people in employment in the UK in the second quarter of 2025 according to the UK Government. In the USA, 42.2% of people aged between 16 and 24 with a disability are either actively looking for work or in employment, according to the U.S. Department of Labor.

Underestimating your disabled audience or customer base doesn’t just limit inclusion; it limits growth, innovation, and profitability.

Next steps

Learn about building a culture of accessibility in our blog post, and consider the Sustainable Accessibility service to ensure accessibility is part of your organisation's DNA.

Her home is filled with music, cat hair, and the occasional badly-strummed ukulele, and she can often be found on morning calls bundled up in a jumper and hat, so fluffy her cats would be proud. Whether she’s deep in an accessibility assessment or sharing knowledge in a workshop, Grace brings insight, curiosity, and a strong belief that digital experiences should work for everyone.

With more than 15 years of experience across the tech industry—from design to front-end development—Grace has increasingly focused her work on accessibility standards and testing. She has assessed a wide range of digital products, including Figma designs for NHS services as part of GDS assessments, detailed code reviews and ongoing consultancy for public sector organisations such as the Climate Disclosure Project, and accessibility audits for many well-known brands across websites and native apps.

Alongside her assessment work, Grace is passionate about helping others grow. She regularly delivers training talks and workshops, and she mentors aspiring developers on accessibility fundamentals through Frontend Mentor, supporting the next generation of inclusive practitioners.

Grace’s career path has been anything but linear. Before finding her place in accessibility, she moved through a remarkable range of roles, including in hotels and retail, where she learned the value of clear communication and empathy. She spent time in journalism, copywriting, and public relations, discovering how to tell stories and make information understandable. Later, estate agency, design, and front-end development gave her a deeper appreciation of how people interact with both physical and digital spaces. She even took a detour into the mountains for a season as a ski instructor!

While she’s tried on many hats, accessibility, inclusion, and teaching are where she feels most at home, and where her varied background comes together beautifully.

What’s the one thing you wish you’d known when you started learning about accessibility?

I wish I'd realised sooner that accessibility isn't just a concern for developers; it starts with design and user experience (UX). When I began my career, I focused on usability but mistakenly thought that any design could be made accessible later in the development phase.

It took me a long time to fully grasp the significant impact my initial design choices had on making a digital product inclusive for people with disabilities. Had I familiarised myself with accessible UI patterns earlier, my designs would have been inherently more inclusive and better documented, which would in turn make developers' and testers' jobs of supporting accessibility much simpler.

Early on, I was stuck in a rigid "right and wrong" mindset. This, combined with my passion for inclusion, often led me to communicate brusquely, which could put people off or make accessibility feel like an impossible task.

Now, I focus on learning to communicate more gently, prioritising the highest-impact accessibility barriers, and providing balanced feedback that encourages progress. Most people genuinely want to build inclusive products; the key is helping them harness that intention without creating feelings of guilt or overwhelm.

What’s your top accessibility tip?

My top tip is to embrace the mindset of progress over perfection and learn to prioritise.

Accessibility can seem overwhelming, but you don't have to fix every issue on every page on day one. Instead, focus your efforts on the most significant barriers that exclude the largest number of users, such as ensuring keyboard navigation is robust or fixing critical colour contrast issues. Make small, sustainable improvements that compound over time. Continuous, measured progress is far more valuable than aiming for unattainable perfection, which can lead to burnout or inaction.

Secondly, don't be afraid to redesign when a "fix" isn't enough—especially after testing with assistive technology users. While meeting WCAG success criteria is essential, sometimes true accessibility requires going beyond the letter of the law and following those "best practice" recommendations as well.

If you realise a pattern or component fundamentally doesn't work well for people who use screen readers, magnification or keyboards, or those with cognitive impairments, don't try to bandage it. Have the courage to go back and simplify, rethink, or even completely redesign the component. This commitment to user experience is what separates merely compliant products from truly accessible ones.

What’s your top accessibility resource?

For those working directly in product and engineering roles, the Understanding WCAG 2.2 Docs and the ARIA Authoring Practices Guide (APG) Patterns are severely under-utilised and are my top technical resources. The Understanding documents move beyond the success criteria to explain why each rule exists and how to meet it, offering crucial context for developers and testers. Similarly, the APG provides practical, tested examples of how to build common accessible component patterns, which is invaluable for ensuring your interactive elements work correctly with assistive technologies.

Familiarity with these patterns helps designers and developers, in particular, gain a shared understanding of which patterns to follow and how different designs can be translated into accessible code. And you don't need to learn it all at once; design and engineering teams (including managers and product owners) can set a manageable goal, such as reviewing one pattern or understanding a document per week, to build their practical knowledge.

For anyone who is new to the field or looking for a foundational understanding of accessibility, I cannot recommend the W3C's Introduction to Accessibility course enough. I believe everyone in the tech industry, regardless of their specific role, should take this training. It provides a vital, empathetic view of how people with disabilities interact with digital products and services day-to-day, which is critical for moving beyond checkbox compliance. This comprehensive empathy-building is the best way to foster a truly inclusive culture within your organisation.

Next steps

Find out more about TetraLogical, the team, our principles and our community.

These challenges are common, but with the right foundations and committed leadership, accessibility can scale in ways that are both effective and sustainable.

A good starting point for scaling sustainable accessibility is to identify your biggest pain points and look at how to reduce or remove them. These often fall into three areas:

• Strategic foundations
• Organisational realities
• External factors

In this post, we explore strategic foundations, and how clear leadership, defined accountability, and effective governance turns intention into lasting change.

A note on EN 17161: Design for All

If you’re looking for a standards-based framework for embedding accessibility into your organisation, EN 17161: Design for All offers useful guidance. Our post Understanding EN 17161 Design for All explains the standard in more detail and is mapped to each of the sections that follow.

Strategic foundations

Strategic foundations help define how accessibility is led, who is responsible, how progress is governed, and how impact is measured through reporting and metrics.

Leadership

Leadership sets the tone, priority, and direction for accessibility across the organisation. Without visible support from senior leaders, it can be difficult to gain momentum or make progress.

A common challenge for organisations is deciding where accessibility leadership should sit. This can result in accessibility becoming a nomad and being passed around various heads of department or treated as an add-on to another leadership role. This often leads to stalled progress, slower decision-making, delayed budget approvals, and a lack of a clear strategy.

There are different approaches to where accessibility leadership can sit within an organisation; what matters most is that it has the authority, visibility, and influence needed to drive change.

Here are a few models we have seen in organisations we have worked with.

Within a central digital or technology team

An obvious choice is for accessibility leadership to sit within a central digital or technology team, as this puts accessibility at the centre of product development, user experience, design, and engineering. In our experience, accessibility most often falls under User Experience and Design, where it’s seen as part of creating an inclusive user journey.

The only drawback is that accessibility may be seen as solely a technology concern rather than a company-wide responsibility. To avoid this, it’s important to align accessibility leadership with other key functions such as Diversity, Equity and Inclusion (DEI), Human Resources (HR), procurement, legal, and communications.

Within a diversity, equity, and inclusion (DEI) team

By having accessibility sit within a DEI team, it becomes more of a company-wide concern and a mindset. This goes a long way to help build a culture of inclusion across all departments, not just digital.

However, DEI may lack technical or operational influence unless aligned with product teams.

While this model is less common, it can work well when DEI and the central accessibility teams collaborate closely, combining cultural leadership with practical implementation.

Within a central accessibility team

A common location for accessibility leadership to st is within a central accessibility team. This helps build specialist expertise and supports consistency across departments. However, it needs strong executive support and mandates to avoid becoming underused, ignored, or avoided by product teams.

An established central accessibility team is an approach we have seen work well for many of our customers. The most effective examples are where the team focuses on building and maintaining an accessibility framework, rather than spending their time on assessments, design reviews, or day-to-day testing.

This frees the accessibility team up to focus on accessibility documentation, processes, and training that benefit every product team, not just one team. It also helps product teams build accountability and embed accessibility into their everyday work, turning the accessibility team into a strategic partner they can call on when specialist support is needed.

Within legal, risk, or compliance

A less common approach is accessibility leadership as part of legal or compliance. While this reinforces the legal obligation to meet accessibility standards, it risks framing accessibility purely as a compliance issue, rather than a design and user experience opportunity.

This is not a model we tend to see amongst our customers.

Executive leadership

Leadership for accessibility sometimes sits with a member of the executive team, such as the Chief Technology Officer (CTO), Chief Operating Officer (COO), or Chief Executive Officer (CEO). This gives accessibility strategic weight and ensures it is embedded across departments from the top down.

Success, however, depends on the executive’s commitment and ability to balance accessibility with other business goals. This model works best when senior leaders reporting into them handle day-to-day implementation and strategic direction, and can escalate issues to executive leadership when needed.

Mapping leadership to EN 17161: Design for All

Understanding EN 17161 Design for All contains more details of the following clauses:

• Clause 5: Leadership
• Clause 9.3: Management review

Responsibility and accountability

Ownership and accountability clarifies who is responsible for what throughout the product delivery lifecycle. If teams are unsure who is responsible for accessibility, it can result in accessibility being left out of product requirements, leading to products being shipped with poor or no accessibility. This can lead to costly retrofitting, legal risk, and potential reputational damage.

At the product team level, ownership and accountability simply means being responsible for whatever you design, code, write, or test. But this can't happen on trust alone; responsibilities should be communicated and supported.

There are a few ways you can do this.

Job descriptions

Accessibility responsibilities should be clearly outlined in job descriptions, so that expectations are transparent from the start. This helps organisations attract and recruit the best candidates as well as help people understand what the role involves.

Once in post, this reinforces accessibility as integral to the role, helps people prioritise it in their day-to-day work, and ensures accountability during performance reviews. It also makes accessibility part of professional development, encouraging continuous learning and improvement across teams.

Objectives and performance reviews

Accessibility responsibilities should also be reflected in individual objectives and performance reviews. This reinforces that inclusion is a core part of quality work, not an optional extra. It helps embed accessibility into everyday practice, ensures accountability over time, and recognises the contribution people make to improving accessibility across products and processes.

I’ve worked in a central accessibility team at a broadcaster, supporting designers, developers, and their managers to add accessibility into individual objectives that linked back to the organisation’s accessibility roadmap and strategy. This had a huge impact, giving teams a clear way to measure progress at both individual and departmental levels.

Built into workflows and processes

Accessibility should be embedded into existing workflows and processes rather than treated as a separate or one-off task. From design reviews and sprint planning to code reviews and Quality Assurance (QA), accessibility should be part of how work gets done day to day.

Embedding accessibility in this way makes it a shared responsibility rather than a specialist task. It ensures that everyone involved in design and delivery is accountable for their part, whether they are designing, coding, writing, or managing a product. This can be done through adding accessibility to documentation, providing accessibility training, tools, and resources to help people do their jobs confidently and effectively.

Shared team goals

Include accessibility in team-wide goals and planning cycles, such as sprint planning or quarterly targets. This embeds it in everyone’s workflow and shifts the focus from individual effort to collective responsibility. It also creates shared accountability, making the whole team answerable for progress, not just those with accessibility in their title.

Named leads and points of contact

Assign a clear lead for each accessibility focus area, deliverable, or decision. This creates individual responsibility for each area, while keeping the team collectively accountable for outcomes. A named contact also reduces ambiguity, speeds up decision-making, and makes it easier for others to ask questions or escalate issues early.

In product delivery teams, this might mean assigning an accessibility lead within design, development, and quality assurance while working collaboratively. A named lead might also be a product manager who owns accessibility in the roadmap. It could also mean embedding a product accessibility specialist in the team. Their role focuses on supporting a single product, unlike an accessibility lead in a central accessibility team, who supports multiple teams across the organisation.

Mapping responsibility, accountability and EN 17161: Design for All

Understanding EN 17161 Design for All contains more details of the following clauses:

• Clause 5.3: Organisational roles, responsibilities and authorities
• Clause 7.3: Awareness

Governance

Effective governance gives accessibility structure, clarity, and authority. It defines who makes decisions, owns and maintains policy, and provides clear escalation routes when issues arise. This helps ensure that accessibility is considered not only in product delivery, but also in recruitment, procurement, and wider organisational decisions.

In practice, this often takes the form of a central accessibility steering group made up of people from across the organisation, such as product, legal, HR, and procurement. Delivery teams can have nominated accessibility leads who feed into the group, monitor progress in their area, and raise issues when support or decisions are needed.

We’ve seen this work well at a global freight company early in their accessibility journey. A steering group of executive leaders owns accessibility, while leads from user experience and design drive day-to-day implementation and strategy, reporting into the group.

Mapping governance and EN 17161: Design for All

Understanding EN 17161 Design for All contains more details of the following clauses:

• Clause 6: Planning
• Clause 9: Performance evaluation

Reporting and metrics

Reporting and metrics are a key part of effective governance. It allows organisations to track accessibility progress beyond individual projects or teams, providing a clear view of what’s working, which products pose an accessibility risk, and where support is needed. Regular reporting helps hold teams accountable, measure whether commitments are being met, and surface risks early. This, in turn, gives senior leaders the evidence they need to drive change.

Examples of organisational tracking include:

• Accessibility roadmaps: track organisational progress against goals, milestones, and delivery timeline, metrics may include policy compliance rates, team training completion, and progress against organisational accessibility goals
• Risk analysis: identify and log accessibility risks within products or services and link each risk to an owner and mitigation plan
• Executive updates: regular updates as a standing item in quarterly business reviews alongside other key performance indicators with clear RAG (Red/Amber/Green) status, risks, and owner actions
• Performance reviews: these can be used to track not only individual progress but also linked to team objectives for reporting data

Mapping reporting, metrics, and EN 17161: Design for All

Understanding EN 17161 Design for All contains more details of the following clauses:

• Clause 6: Planning
• Clause 8: Operation
• Clause 9: Performance evaluation

In summary

Scaling accessibility in organisations can be complex, but it’s achievable with the right approach. Success depends on strong leadership, clear accountability, effective governance, and consistent metrics supported by a culture that values inclusion and collaboration.

By taking a structured, joined-up approach, combined with careful management of organisational realities and external factors, you can scale accessibility in a way that delivers long-term value for your teams, your business, and your customers.

Next steps

Learn more about how TetraLogical can help your organisation with our Embedded accessibility service and Sustainable accessibility service.

These challenges are common, but with the right culture, good communication, planning, and collaboration between teams, accessibility can scale in ways that are both effective and sustainable.

A good starting point for scaling sustainable accessibility is to identify your biggest pain points and look at how to reduce or remove them. These often fall into three areas:

• Strategic foundations
• Organisational realities
• External factors

In this post, we explore organisational realities and what it takes to build a culture of inclusion, open communication, and collaboration across teams and processes.

A note on EN 17161: Design for All

If you’re looking for a standards-based framework for embedding accessibility into your organisation, EN 17161: Design for All offers useful guidance. Our post Understanding EN 17161 Design for All explains the standard in more detail and is mapped to each of the sections that follow.

Organisational realities

Organisational realities such as culture, departmental politics, siloed teams, and budget constraints can all affect how accessibility is implemented, regardless of the strategic foundations in place. When tackled head-on, they can help unlock lasting change rather than act as a blocker.

Culture

By building a culture of accessibility, you shape how inclusion is understood and prioritised and whether it’s seen as everyone’s responsibility or left to a few specialists. It also influences whether teams think of accessibility as a driver of innovation or a compliance burden.

An inclusive culture goes far beyond product teams. It’s a shared mindset across the organisation, reflected in many different teams, for example:

• How Human Resources (HR) designs inclusive recruitment processes
• How procurement sets accessibility criteria for suppliers
• How legal manages risk and compliance
• How marketing and communications teams ensure accessible content
• How leadership sets expectations through strategy and tone
• How people use inclusive language when working with each other and our customers

Mapping culture and EN 17161: Design for All

Understanding EN 17161 Design for All contains more details of the following clauses:

• Clause 6: Planning
• Clause 7: Support

Change and communication

Scaling accessibility often requires shifts in mindset, habits, and ways of working across the organisation. This kind of change doesn’t happen automatically; it needs time, coordination, and clear communication.

That’s where dedicated change management and internal communication functions can make a big difference. They help teams understand not just what needs to change, but why it matters and how to make it happen.

There are a few ways to support change more effectively:

• Change managers: use change managers to embed accessibility into transformation work. If your organisation is going through broader digital, cultural, or operational change, accessibility should be part of that transformation from the start and not added in later
• Change programme: treat accessibility as an organisational change programme; even if you’re not restructuring, scaling accessibility still requires changes to roles, responsibilities, behaviours, and systems so a structured change approach can help teams adapt and stay aligned
• Internal communications: partner with your internal communications team to embed accessibility into company-wide campaigns, announcements, and messaging. This keeps accessibility visible, normalises inclusive practices, and helps shift culture
• Share success: tell stories and share successes, use internal channels to highlight accessible design wins, individual contributions, and the impact accessibility has on real people. This helps build motivation and reinforces a shared commitment

We’ve seen the value of change management firsthand when working with a global freight company at the very start of their accessibility journey. With no previous accessibility policies, processes, or training in place, the organisation needed more than just technical recommendations — it needed a shift in mindset and ways of working, starting at the very top with leadership.

We’ve also worked with change management at a broadcaster with many years of accessibility experience and expertise as they went through organisational change. The change manager played a critical role in preserving accessibility knowledge during team restructures, ensuring it wasn’t lost as people changed roles or left the organisation. They helped embed accessibility into new ways of working, updated internal processes and training, and made sure accessibility remained part of the conversation as new leadership and priorities emerged.

Mapping change, communication and EN 17161: Design for All

Understanding EN 17161 Design for All contains more details of the following clauses:

• Clause 7: Support
• Clause 6.3: Planning for changes

Departmental politics

Departmental politics can have a significant impact on how accessibility is prioritised, funded, and implemented. Competing goals, unclear ownership, or internal rivalry can slow progress and create unnecessary barriers. Even when leadership support exists, the dynamics between teams can determine whether accessibility work moves forward or gets deprioritised.

This often happens when accessibility sits between teams, for example, when product, design, or engineering each assumes another team is responsible. Without shared priorities and clear escalation routes, accessibility decisions can be delayed, diluted, or reversed, making long-term progress difficult.

There are a few ways to manage departmental politics more effectively:

• Create shared priorities: make accessibility part of cross-departmental planning so it’s not seen as a single team’s responsibility or competing objective
• Align incentives and goals: include accessibility outcomes in departmental objectives so that success depends on collaboration, not competition
• Clarify accountability: use governance structures to define who decides, who delivers, and who approves accessibility work across departments
• Encourage transparency: use shared reporting, open forums, or regular updates so accessibility progress is visible and less vulnerable to competing agendas
• Secure executive sponsorship: when senior leaders reinforce accessibility as a shared organisational goal, it’s easier for teams to align and reduce friction

Mapping departmental politics and EN 17161: Design for All

Understanding EN 17161 Design for All contains more details of the following clauses:

• Clause 6.3: Planning for changes
• Clause 8: Operation
• Clause 8.1: Operation planning and control

Siloed teams

Even in organisations where departmental priorities are aligned, accessibility can still be slowed down by teams working in silos. These are often not political divides, but structural ones caused by different systems, workflows, or locations that limit collaboration and knowledge sharing.

Siloed teams can unknowingly duplicate work, overlook accessibility requirements, or develop inconsistent approaches. People may be solving the same problems in different ways — or not solving them at all. This results in fragmented user experiences and uneven accessibility maturity across products and services.

There are a few ways to break down silos and improve consistency:

• Design systems: a central design system team creates accessible components and shares usage guidance across product teams
• Shared standards: a single set of accessibility guidelines that all teams can reference
• Cross-team training: shared training ensures everyone has a consistent understanding of accessibility principles and practices
• Accessibility champions network: a network of accessibility champions from different teams who meet regularly to share progress, align practices, and support each other’s work
• Central resources: documentation, training, and tools that are available to all teams in a central hub, ensuring accessibility knowledge is easy to find and maintain
• Shared goals: accessibility goals or key performance indicators (KPIs) that encourage collaboration across teams working on related products or services

Many organisations we work with have an accessibility champions network that can go a long way to connecting otherwise dispersed groups of people. How An Accessibility Champions Network Started The BBC’s Story by Gareth Ford-Williams offers lots of useful insights. Another great resource is the Champions of Accessibility Network, where companies and people share resources and ideas for running accessibility champion networks.

Mapping siloed teams and EN 17161: Design for All

Understanding EN 17161 Design for All contains more details of the following clauses:

• Clause 6.3: Planning for changes
• Clause 8: Operation
• Clause 8.1: Operation planning and control

Budget

Budget constraints are one of the most common organisational realities. Ideally, budgeting cycles include accessibility as standard alongside security, performance, or outsourced design and development support. If not, start early by making the business case for accessibility.

When planning your budget, consider costs such as:

• Training: accessibility training either built into team training plans or accounted for in a central training hub the whole organisation can access
• Specialist support: budget for assessments, usability testing with disabled people, or embedded accessibility support from third parties
• Tools: software for design and development teams, such as screen readers, automated testing tools, and plug-ins
• Recruitment: budget for recruitment support people into the team with appropriate accessibility knowledge and experience

As Felicity Miners-Jones explains in her accessible recruitment post, it's important to make each stage of the hiring process through to onboarding and beyond accessible so that you can attract the best candidates from a range of backgrounds and disabilities.

Mapping budget and EN 17161: Design for All

Understanding EN 17161 Design for All contains more details of the following clauses:

• Clause 7.1: Resources
• Clause 8.5: Control of and communication with external suppliers

Outsourcing and third parties

Outsourcing extends accessibility responsibilities beyond your direct control. To avoid accessibility being diluted or lost, requirements must be built into procurement and third-party management processes from the start.

Whether you’re buying tools, commissioning content, or contracting design and development services, procurement teams and product leads should work together to include clear accessibility expectations in briefs, selection criteria, and contracts. As part of the selection process, vendors should be asked to provide accessibility statements, test or assessment results to demonstrate they have met accessibility standards.

Once selected, product leads must ensure third parties continue to deliver against those expectations. This means monitoring quality, building accessibility into acceptance criteria, and following up where issues arise.

We've worked with customers where we've not only trained their User Experience and Design teams, but also their supplier network who support them with user research and design. This ensures there is a shared mindset, knowledge, and language they can all use when collaborating on projects.

Mapping outsourcing, third parties, and EN 17161: Design for All

Understanding EN 17161 Design for All contains more details of the following clauses:

• Clause 7.1: Resources
• Clause 8.5: Control of and communication with external suppliers

In summary

Scaling accessibility in organisations can be complex, but with the right culture, good communication, planning, and collaboration between teams, accessibility can scale in ways that are both effective and sustainable.

By taking a structured, joined-up approach, combining strategic foundations and careful management of external factors, you can scale accessibility in a way that delivers long-term value for your teams, your business, and your customers.

Next steps

Learn more about how TetraLogical can help your organisation with our Embedded accessibility service and Sustainable accessibility service.

These challenges are common, but by anticipating changes in the accessibility landscape and wider economic environment, you can make progress that is both effective and sustainable.

A good starting point for scaling sustainable accessibility is to identify your biggest pain points and look at how to reduce or remove them. These often fall into three areas:

• Strategic foundations
• Organisational realities
• External factors

In this post, we explore external factors and how anticipating changes in the accessibility landscape and wider economic environment can help you sustain progress through change.

A note on EN 17161: Design for All

If you’re looking for a standards-based framework for embedding accessibility into your organisation, EN 17161: Design for All offers useful guidance. Our post Understanding EN 17161 Design for All explains the standard in more detail and is mapped to each of the sections that follow.

External factors

Even with strong leadership and a clear internal strategy, accessibility can still be shaped by factors outside your organisation’s direct control. These include regulatory requirements, supplier capability, technology constraints, and customer expectations.

International operations

For global organisations, scaling accessibility consistently across regions brings additional complexity. Legal requirements can differ from country to country, and cultural expectations will shape how disability and accessibility are perceived and prioritised.

Without clear, unified guidance, local teams can be left unsure which standards to follow or how to adapt accessibility practices in a way that works for their region. This can result in duplicated effort, inconsistent experiences, and localised risk.

There are a few ways to support international operations more effectively:

• Create a global accessibility framework: establish shared accessibility principles based on international standards such as WCAG, then supplement them with regional guidance to reflect local laws, user needs, and languages
• Assign regional accessibility leads: regional leads act as local points of contact and ensure that accessibility is implemented consistently, while adapting it appropriately for their market as well as representing local issues to central governance teams
• Provide training and resources in local languages: support teams in applying accessibility best practices by offering training, documentation, and tools that are tailored to regional contexts
• Track progress regionally: use reporting and metrics to monitor accessibility maturity by region and surface local risks, blockers, and successes to central governance teams

Mapping international operations and EN 17161: Design for All

Understanding EN 17161 Design for All contains more details of the following clauses:

• Clause 4.2: Understanding the organisation and its context
• Clause 6: Planning

Changes in accessibility standards

Accessibility standards and guidelines are not static; they continue to evolve. The release of WCAG 2.2 introduced new WCAG 2.2 success criteria focused on cognitive accessibility and mobile usability, and WCAG 3.0 is on the horizon, promising a more flexible and outcomes-based approach.

For many organisations, keeping up with these changes can be difficult, especially when multiple teams work across different platforms, tools, and delivery models.

There are a few ways to manage changes in standards more effectively:

• Monitor standards and regulations regularly: assign responsibility to a central accessibility team, legal function, or risk owner to stay up to date with new versions of WCAG, evolving assistive technologies, and changes in national or regional laws
• Maintain a living accessibility framework: keep internal guidance, policies, and design system documentation up to date by reviewing them on a regular schedule and when significant updates to standards are released
• Communicate changes clearly and early: Share updates across the organisation in a coordinated way, ideally with clear explanations of what has changed, who it affects, and what action is needed
• Plan for incremental adoption: rather than trying to meet every new success criterion immediately, prioritise updates based on user impact, feasibility, and regulatory relevance; this helps teams act without feeling overwhelmed
• Build it into governance: include standards updates as a standing item in accessibility governance meetings so changes can be reviewed and ownership agreed

Mapping changes in accessibility standards and EN 17161: Design for All

Understanding EN 17161 Design for All contains more details of the following clauses:

• Clause 6: Planning

Recessions, cutbacks, and restructures

Economic downturns, budget cuts, and restructuring can put accessibility at risk, especially when teams are under pressure to reduce costs, reallocate resources, or move faster. Accessibility work may be seen as optional, specialist, or something that can be deprioritised “for now.”

But letting go of accessibility can introduce long-term costs: inaccessible products, frustrated users, legal risk, and expensive remediation. Even when budgets are tight, maintaining the accessibility practices you’ve already put in place can be a cost-efficient way to reduce risk and preserve quality.

There are a few ways to do this:

• Maintain what’s already embedded: accessibility that’s part of your design systems, workflows, and team responsibilities doesn’t cost extra to maintain; keeping those practices in place ensures consistency without needing additional investment
• Focus on high-impact areas: prioritise accessibility work where it matters most, such as critical user journeys, high-risk products, or areas with customer feedback so effort is targeted and effective
• Use reporting to show value: continue tracking and reporting accessibility progress so leaders can see where it’s having an impact, and what could be lost if it’s dropped
• Treat accessibility as a risk, not a nice-to-have: include accessibility in your risk models and legal frameworks so it’s seen as essential to product quality and compliance
• Document and decentralise: Make sure guidance, decisions, and tools are documented and shared in central locations where current and new employees have visibility

Mapping economic pressure, organisational change and EN 17161: Design for All

Understanding EN 17161 Design for All contains more details of the following clauses:

• Clause 7.1: Resources
• Clause 6: Planning

In summary

Scaling accessibility within organisations is complex, but by anticipating changes in the accessibility landscape and wider economic environment, you can make progress that is both effective and sustainable.

By taking a structured, joined-up approach, combining strategic foundations and careful management of organisational realities, you can scale accessibility in a way that delivers long-term value for your teams, your business, and your customers.

Next steps

Learn more about how TetraLogical can help your organisation with our Embedded accessibility service and Sustainable accessibility service.

Screen readers are software applications that convert on-screen content into audio, reading aloud what’s displayed on your laptop or mobile screen. For more information on how they work, visit browsing with a desktop screen reader and browsing with a mobile screen reader.

Despite their widespread use, there are still many misconceptions about how screen readers work and how people interact with them. We explore some of these below.

Misconception 1: only blind people use screen readers

Probably the biggest misconception around screen readers is that they are only used by people who are blind. This is far from reality. WebAIM's latest Screen Reader User Survey shows that only 77% of respondents identified as being blind.

Many people may access digital content with a screen reader, for different reasons. For example:

• People with seeing disabilities: blind, Deafblind, and many people with low vision commonly use screen readers as they cannot see the content on screen
• People with thinking disabilities: some people with ADHD or learning and reading disabilities find that screen readers help them focus on, and understand, written content
• People with variable disabilities: people with conditions whose symptoms vary throughout a day or from day to day may switch to using screen readers when they find reading content too tiring
• People with situational disabilities: screen readers can be useful in situations where it's not possible to look at a screen, such as when cooking while following an online recipe

Read about the experience of some screen reader users:

• Meet Andre: a music producer and blind screen reader user
• Meet Hasmukh: a blind cricketer and screen reader user
• Meet Lauren: a film editor who has ADHD

Misconception 2: people use screen readers in the same way

With so many people using screen readers for different reasons, it's only natural that each person's experience is unique.

People adjust their screen reader's settings and choose a navigation method to suit their needs and preferences. Two people with the same disability using the same screen reader may still have very different experiences.

Some people use screen readers in combination with other assistive technology - for example a Deafblind person may use it together with a refreshable Braille display while someone with low vision may use it together with screen magnification software. The input device used to navigate web content can also differ; blind people will use a keyboard while low vision or sighted people may use a mouse and a keyboard. And people with thinking disabilities may choose to have text highlighted as the screen reader announces it.

It's often impossible to predict how someone will use a screen reader. The best way to learn about the different strategies and methods used by people is to observe User Experience (UX) Testing sessions.

Misconception 3: all screen readers work in the same way

Several screen readers are available - JAWS, NVDA, and Narrator for Windows machines, VoiceOver for Mac and iOS devices, TalkBack for Android devices, and so on.

While they work in similar ways, there are some key differences. Keyboard commands (on laptops and desktops) and gestures (on touch screen devices) may vary slightly from screen reader to screen reader.

The same applies to how screen readers announce content. As demonstrated in the Screen Reader HTML Support table screen readers can announce elements and labels differently. For example some announce a button as "button" followed by its visible label (such as "button save") others announce the label first ("save button").

This is nothing to worry about, screen reader users are aware of these differences and don't expect all screen readers to work and announce elements in the same way. Trying to force screen readers to behave in any other way is likely to confuse, rather than help, people.

Misconception 4: building a screen reader specific version of a website or app is a good idea

We are sometimes asked whether having a simplified version of a website or app designed and built for screen reader users specifically is a good solution. The answer is, no.

Having separate versions of a product for different groups of people is not an inclusive approach. A more inclusive solution is to build a product that adjusts and supports the needs and preferences of everyone, including screen reader users.

It's not an efficient or sustainable solution either; creating and maintaining different versions of a product requires time and money. By spending just a portion of that time and money to implement accessibility considerations, you can create a product that works better for everybody.

Misconception 5: screen reader users don't care about images

A key accessibility consideration when building content that works for screen reader users is to provide a text description for images. Designers and developers are sometimes unclear on why this is required. Surely screen reader users don't care about images, right?

As discussed under Misconception 1: only blind people use screen readers, not all people using screen readers are blind. Some may have enough vision to know that an image is on the screen but not to make out its content. And some people with thinking disabilities may see the image but struggle to interpret it. All these people expect their screen reader to describe the image for them.

Some blind people also really appreciate images being described. This is particularly true for people who lost their sight later in life. They may like to know that an image of a sunny, clear sky or of a menacing storm is on a page as that will evoke a particular feeling or emotion.

Misconception 6: screen reader users need instructions on all content

Another common misconception is that screen reader users need instructions on all elements that make up a web page or app screen.

For example, for a page containing an "Add to cart" button, some may assume that including the hidden instruction "Activate the 'Add to cart' button to add the product to your shopping cart" is useful to screen reader users. In fact, this adds unnecessary noise which ultimately worsen people's experience on the website or mobile app.

Just as you wouldn’t include instructions on how to use buttons or links for sighted users, there’s no need to explain how to operate them for screen reader users.

As long as elements are coded following best accessibility practice, screen readers provide all necessary information by default. For example, when reaching an element coded as a button, they announce it as a button and read out its visible label. People are then able to activate the button using their screen reader default keyboard command or gesture.

Misconception 7: all content must be focusable to work with screen readers

Many screen reader users, especially if blind, navigate web content using a keyboard. This doesn't mean all content must be keyboard focusable.

Screen reader users have a wide range of keyboard commands at their disposal. Unlike people who use a keyboard without a screen reader, they can navigate to all sorts of focusable and non-focusable items.

For example, they can reach a new line of static text by pressing the down arrow key; the next heading on screen by pressing the H key; the next page section (like the header, main or footer) by using the D key; and so on.

Trying to make all content keyboard accessible is not needed and is going to interfere with the way screen reader users navigate websites.

The principles were developed to plug that gap with people-centred guidance that helps teams make better design decisions without adding unnecessary complexity. In this post, we'll look at who the principles are for, what they can be applied to, how they help people, and how you can integrate them into your own practices.

The seven principles

Firstly let's look at each of the seven principles and what they are.

Provide a comparable experience

Ensure your interface provides a comparable experience for all so people can accomplish tasks in a way that suits their needs without undermining the quality of the content.

Providing a comparable experience is more than just adding alternatives for images, video, and audio. Those alternatives need to be high quality so that people who experience the web in different ways have content that is just as effective. After all, text descriptions, captions, audio description, and transcripts are not supplementary, they are primary content for many of us.

Inclusion goes further still: however someone consumes or navigates content, whether with assistive technology or an adaptive strategy, their experience should be just as usable and enjoyable as anyone else’s, not just technically accessible.

Consider situation

People use your interface in different situations. Make sure your interface delivers a valuable experience to people regardless of their circumstances.

Inclusive design isn’t just about the interface; it’s also about the context in which someone is using it. Accessibility and usability can be affected by a person’s environment, or by how they’re feeling mentally or physically.

A well-designed interface should work just as well for someone using it on a crowded train with limited signal, as it does for someone at home with full concentration. Designing with context in mind means recognising that people’s abilities and needs change - sometimes temporarily, sometimes permanently — and ensuring your product adapts to meet them.

Be consistent

Use familiar conventions and apply them consistently.

Consistency is key. It helps people navigate with confidence, reduces cognitive load, and builds familiarity with your product. The goal is to balance innovation with familiar conventions and learned behaviours.

Internal consistency means using your organisation’s design system and adhering to shared patterns. This could include consistent keyboard behaviour across components, or language guidelines that shape how instructions, buttons, and links are written across your product.

External consistency means following established web conventions that people have come to expect such as search positioned high up in the content order in the top-right corner, or commonly used icons. These patterns reduce the need for people to relearn how things work.

Give control

Ensure people are in control. People should be able to access and interact with content in their preferred way.

Giving control means respecting how people choose to experience content, not forcing a one-size-fits-all approach. It ensures that people can adjust how content is displayed using their own assistive technologies, adaptive strategies, or preferences without being blocked by restrictive design decisions.

This shouldn't limit creativity or innovation, it simply means designing in ways that don’t override people's needs. For example, people should be able to pause or disable animations and videos, stop auto-advancing carousels, zoom without layout breaking, and adjust font sizes or colours to support readability.

Offer choice

Consider providing different ways for people to complete tasks, especially those that are complex or non-standard.

Not to be confused with “give control,” offering choice is about providing multiple ways for people to complete the same tasks, especially when those tasks are complex, unfamiliar, or require specific interactions.

This might mean allowing people to drag and drop or use standard form fields, complete a form online or download it to fill out offline, or access support through a live chat or a help article.

Prioritise content

Help users focus on core tasks, features, and information by prioritising them within the content and layout.

Prioritising content is often overlooked in design, but when done well, it has a huge positive impact on accessibility and inclusion.

By putting the most important tasks, features, and information high up in the content order, you reduce cognitive load and help people complete what they came to do, faster and with less frustration. This is especially important for non-mouse users and people with limited time, lower literacy, or attention-related disabilities.

Good content prioritisation is more than just a thoughtful content order however, it’s also about making information easy to scan, read, and act on. This includes using keywords at the start of headings and link text, writing clear copy that puts the main point first, and removing anything that distracts or overwhelms.

Add value

Consider the value of features and how they improve the experience for different users.

There is a big crossover between adding value and innovation, but innovation isn’t valuable if it creates barriers or complexity.

Adding value means introducing features or enhancements that genuinely support accessibility and inclusion. This might mean adding features that facilitate task completion such as a show password toggle, voice input options in search and forms, or customisable notification settings.

What the principles can be applied to

The principles can be applied to any type of interface including, but not limited to:

• Automotive interfaces: in-car entertainment and navigation systems
• Biometrics: fingerprint, face, or voice recognition systems
• Chatbots: conversational text-based interfaces
• Kiosks: touchscreens and public access terminals
• Mobile applications: apps for smartphones and tablets
• QA codes: machine-readable codes used to access digital content
• AR/VR interfaces: augmented and virtual reality environments
• Smart TV interfaces: menus and apps for televisions and streaming devices
• Smart home interfaces: control panels, apps, and voice assistants for connected devices
• Voice interfaces: systems controlled by speech
• Wearables: smartwatches, fitness trackers, and other devices with small screens
• Websites: online content and services

You can also apply them when mapping out:

• User flows and user journeys: ensuring that each step of a process works for people with different needs and preferences
• Product blueprints: identifying requirements for a product and ensuring they are inclusive
• Content strategy and structure: shaping content so it can be understood and used by everyone
• Design systems and component libraries: ensuring consistency and inclusion are embedded across reusable patterns

Who are the principles for

Simply put, they are for everyone involved in the design, development, and delivery of digital products and services. This includes:

• Designers including UX, UI, and service designers
• Developers
• Content designers and writers
• Product managers and owners
• Quality assurance (QA) testers
• Researchers and user experience specialists

How do the principles help people

The principles help people designing and building interfaces as well as disabled people using interfaces.

People designing and building products

The principles can support product teams in several ways, by:

• Embedding inclusion from the start: providing a shared language and framework that guides teams to make design decisions that include, rather than exclude, people right from the start
• Improving decision-making: helping teams weigh design trade-offs with inclusion in mind
• Reducing remediation work: minimising the need for costly accessibility fixes later in development
• Going beyond compliance: focusing on user experience rather than just ticking boxes in a guideline

People using products

The Inclusive Design Principles help people using products by:

• Prioritising people with disabilities: leading to designs that accommodate a wider range of experiences from the start
• Improving usability for everyone: by considering the needs of disabled people, you will get a product that is more usable for everyone to use
• Creating a culture of inclusion: using the principles throughout the design and build process helps build a mindset of inclusion and gradually build better understanding around the different needs of disabled people

How can the principles be used

The Inclusive Design Principles can be applied throughout the product development lifecycle, from early research through to delivery and quality assurance.

During research and discovery

The principles can be used to shape inclusive thinking from the start.

Framing research questions

The principles can be used to help inform research questions. For example:

Is this a comparable experience for someone using a screen reader or voice input?

or

How can we offer people a choice of more than one way to complete this task?

This ensures your research considers different perspectives from the start.

Documenting accessibility requirements

The principles can act as a reference for requirements. For example, if you’re designing a dashboard with live updates, the requirement might be:

Ensure people can control when the dashboard is updated.

This helps people with thinking or seeing disabilities who want to avoid unexpected dashboard changes, for example by adding pause, refresh, or update frequency controls.

Ensure people have a choice as to what content appears on the dashboard

This helps people with seeing, moving, and thinking disabilities reduce distractions and unwanted content by allowing personalisation and customisation.

During design

Use the principles in design reviews

Review layouts, interaction patterns, alternatives, and language against the principles. For example, on a charity website this could mean prioritising the donate and get support buttons in the content order and making them visually prominent.

Or it could mean adding value to a search input by including voice input to support people who struggle to input text using a keyboard or spell words correctly.

Accessible design annotations

Capture decisions and feedback in design annotations to clarify intent for developers and QA. This reduces ambiguity, builds understanding, and prevents accessibility from being dropped during handoff, and supports more consistent, inclusive outcomes across teams (Be consistent).

During development

Use the principles to guide coding decisions

The principles can help guide coding decisions when you’re unsure of the best way to implement a feature or component.

For example, if you have two working prototypes, asking how well each one aligns with the Inclusive Design Principles can help reveal which option provides a more inclusive, user-centred experience. Even if both are technically functional, one may better support diverse needs and offer a more comparable experience.

Use the principles alongside WCAG

When paired with WCAG, the principles help ensure interfaces go beyond compliance, creating more thoughtful and inclusive experiences.

WCAG sets essential requirements but cannot fully address design, which is often subjective. The IDP help bridge this gap by showing what good design looks like in the context of your product and the different situations in which people use it.

During testing and quality assurance

The principles can help teams evaluate user experience when usability testing with disabled people isn’t possible through:

• User experience reviews: use the principles as a checklist in component reviews or journey walkthroughs to understand how people with seeing, hearing, moving, and thinking disabilities experience your product.
• Scenario testing: ask questions such as “Can someone pause this animation?” or “Is content clearly prioritised for someone navigating by touch or voice?”

Who is using the principles

Since their release, the IDP have been referenced in design systems, adopted in accessibility programmes, and used as teaching tools in training and education.

We use them every day, and feature in a number of our services such:

• Agile Usability Testing
• Design Reviews
• Design System Assessments
• Documentation
• Embedded Accessibility
• User Experience Reviews

As a consultancy, we design services and solutions that help our customers meet complex challenges. The Inclusive Design Principles shape not only the guidance we give on products and features, but also the strategies and processes that ensure accessibility and inclusion are built into every stage of delivery.

They are also currently used by many organisations all over the world including:

• Council of the European Union (Learning Resources)
• RRC University, Canada
• Centre for Inclusive Design Australia
• Smashing Magazine

Summary

The principles don’t replace WCAG or other standards; they provide a lens for good design that includes everyone. Used consistently, they help shift accessibility from compliance to culture.

Resources

• The inclusive Design Principles - video, Henny Swan
• The Inclusive Design Principles posters - PDF, Barclays

Next steps

For more information about the Web Content Accessibility Guidelines, read our WCAG primer or find out more about how our assessments can help you identify issues in your websites, mobile applications, design systems, and other products and services.

He’s been involved with accessibility and web standards since the early 2000s, back when the Web Standards Project (WaSP) and its Accessibility Task Force were encouraging companies like Macromedia and Adobe to produce tools that generated standards-based, accessible code. At the same time, he was a front-end developer with a habit of talking about accessibility to anyone who would listen.

Lloydi also wrote a book called Build Your Own Website the Right Way Using HTML & CSS, which went on to become a SitePoint bestseller since it was first published almost 20 years ago.

A family man at heart, Lloydi has been married for almost 20 years, raising twins who are, in his words, “two peas from two entirely different plant species’ pods.” His family lives among his old DJ kit and the odd vinyl record released in his name from years ago. The household is completed with two furry friends: Roxy, the Cairn Terrier, and Rambo, a tiny dog of indeterminate breed.

Music has always been a constant, ever since the early days. Before his full-time shift into accessibility in 2019 (when he joined Apple’s UK accessibility team as a contractor), he’d already had a sideline as a DJ and producer, releasing records on vinyl and even landing The Prodigy (Warning: there is strobe lighting on page load) their first magazine front cover back in the 90s (sadly, the physical proof was lost when the magazine got left behind in a house move but this doesn't make it any less true)!

After five years at TPGi as a Principal Accessibility Engineer, Lloydi joined TetraLogical as a Principal Accessibility Specialist. Here, he puts his web development background to use by building prototypes for complex accessibility challenges and creating tools to spot issues that off-the-shelf testing software might miss. He continues to speak at conferences, contribute to books, and is always looking for ways to make accessibility more practical and effective.

When he’s not doing that, you might find him out on his childhood BMX (a 1984 Haro Freestyler for those in the know), or edging back into photography after blaming the iPhone for years of laziness. He’s fully aware that becoming “camera guy” again could be dangerous for the bank balance, but that’s all part of the fun.

All told, whether he’s unpicking accessibility conundrums, producing music, or bombing around on his BMX, Lloydi brings the same mix of persistence, creativity, and slightly mischievous enthusiasm.

What’s the one thing you wish you’d known when you started learning about accessibility?

That one day it'd take over my life?

Seriously, though, when I first started to learn about this stuff back in the early 2000s, everything was much simpler as far as accessibility was concerned. There were very few resources available at the time, other than the early Web Accessibility Initiative (WAI) and Web Content Accessibility Initiative (WCAG) documentation (which was also much simpler - or less comprehensive, if you like) and HTML standards.

Had I known how the web would change, and how we develop for it, I might have chosen to become a welder, park ranger or something else entirely different. The absolute bloated mess that is produced by so many of the current frameworks, production and publishing processes has made the task of creating accessible content so much more difficult. So, practically speaking, I wish that I could have been more involved in the early days of the development of some of these tech stacks. It would have been wonderful to have contributed to the code base early doors and avoid a lot of the issues that are now just wrapped up in what they generate, with limited ability to change them. Having had a few opportunities to provide accessibility feedback and advice on code and markup used in design systems before they are used in production, it's clear how much of a difference this can make to the end product.

When developers are using frameworks like React, it's so much more difficult for people who are providing assessments and consultancy to say, "just fix this HTML here", because the chances are the developers have touched about as much raw HTML as the amount of steel plates I've welded (which is none). So, if you ever have the opportunity to contribute to such things from the outset to head off issues further down the line, I'd definitely encourage doing that!

What’s your top accessibility tip?

This is very much aimed at developers: don't try to be too clever!

Actually, that also applies to UX and designers. It seems like there are plenty of people who will strive to make an interface do something cool, new, or interesting, dismissing years of research, convention, and learned behaviours. We used to see that all the time with Flash-based sites, but Flash is dead, so that's progress of sorts!

It's so important for people from all walks of life to get access to proposed designs before a single line of code has been written. Does the interface look a bit ... funky? Is it obvious what needs to happen here? If the warning bells are starting to sound, there's a chance to put things right. And that's not limited just to accessibility specialists having their say, I should clarify. A designer can't know everything, and along with accessibility issues that they might unwittingly introduce, there may be cultural missteps, confusing language, and who knows what else? The broader the audience who get early access, the better it is for everyone.

What’s your top accessibility resource?

The pages that I refer to most are the WCAG Understanding docs. The normative docs don't really give you the details, they just give you the basic 'what it is'. The understanding docs really help to explain what this means in practice, and they are updated when confusion arises (albeit after some very lengthy and sometimes fraught discussions ... at this point I look in Patrick's direction expecting a knowing nod).

After that, the pages that I reference the most are those that cover patterns for more complex widgets such as the ARIA Authoring Practice Guidelines.

If I may be so cheeky, I'll add one other, which is my own site: a11y-tools.com - mainly for the bookmarklets.

Very much following the 'eat your own dog food' mantra, I use these tools all the time. I often find that while page and site scanning tools like Axe, ARC Toolkit, and Wave provide broad coverage, the way they display issues isn’t always useful. For me, the challenge is "how can I show this in a way that makes sense to the developer who needs to fix it?".

So I create tools and visualisers that expose accessibility issues in a way that makes sense to me, that lend themselves well to a screenshot when filing an issue or sharing with teams. I share these tools with others because I suspect I'm not alone in wanting to visualise issues in this way. I literally use them every day while carrying out assessments, it's definitely a top resource for me (and by me).

Next steps

Find out more about TetraLogical, the team, our principles and our community.

Using a common language that designers, developers, and quality assurance (QA) teams all understand is essential so that information doesn't get lost in translation, especially during the hand-off between design and development.

There are already some great Figma plugins and libraries to help, such as:

• Contrast & Accessibility Checker, by Stark
• Accessibility Assistant, by Microsoft
• A11y Annotation Kit, by Indeed
• axe for Designers, by Deque

These tools can make accessibility annotations easier to manage, but they’re just the starting point. What really matters is knowing what to annotate and how to do it clearly and consistently using language everyone understands.

Why accessibility annotations matter

Most of the time, things aren’t inaccessible because someone deliberately designed them to be that way. They become inaccessible because multiple people throughout the process didn’t consider accessibility. In the fast-paced world of product delivery, if nobody considers accessibility, the product will simply be shipped without it.

As an example, if the designer does not provide text descriptions for editorial images, the development team will usually do one of three things:

1. Leave the alt attribute out altogether, so screen readers fall back to announcing the image file name or URL
2. Provide a text description themselves, which may or may not accurately describe the image in its context
3. Use an empty alt attribute, effectively marking an image as decorative when it shouldn't be

So, by annotating our designs, we help to fill in those gaps for the development team. We clarify our design intent, reduce ambiguity, and save the whole team time by avoiding expensive re-designs, rebuilds, or last-minute bug fixes.

What to annotate

Annotate anything that could affect accessibility or usability, especially when it isn’t obvious just by looking at the design.

For example:

• Action labels: for elements like buttons and links
• Content structure: like heading levels and lists
• Error suggestions: for elements like form inputs with error messages
• Keyboard functionality: like focus order and visible focus styles, keyboard accessibility, and skip links
• Layout: how elements behave at different viewport sizes or breakpoints
• Multimedia alternatives: like audio descriptions, captions and transcripts for inclusive video
• Page titles: which accurately represent the content and orientate the user
• Reading order: for complex layouts or grouped elements
• States: for changes of state such as disabled, invalid, loading, expanded and collapsed
• Text descriptions: for elements like images and icons
• Timings: like durations, time limits, and session time outs

Deciding what's important

To decide what's important to annotate for developers, look at each element and ask three questions:

1. What different outcomes are possible from interacting with this element?

   • Does it change state? For example, selected, expanded or collapsed.
   • Could something go wrong? For example, validation errors.
   • Does it change the current context for the user? For example, opening a modal or navigating to a different page.

2. How might different people achieve each outcome?

   Are they:

   • Browsing with a mouse? For example, clicking, dragging or hovering.
   • Browsing with a screen reader, for example, listening to text descriptions.
   • Browsing with a keyboard? For example, using Tab, Space or Enter keys.
   • Browsing with speech recognition? For example, saying "click button" or "press tab".

3. What isn’t immediately clear just by looking at the design?

   • Are icons ambiguous? For example, an "X" icon could represent "clear", "remove", or "close" actions.
   • Is the content structure ambiguous? For example, different heading levels could look similar in size.
   • Is content ordering ambiguous? For example, a sidebar could be read out before or after the main content.

The current challenge with accessibility annotation tools

The biggest challenge we see with most of the current accessibility annotation tools, is that they usually require the person doing the annotations to have a strong knowledge of HTML and accessibility.

To be honest, although most accessibility annotation tools are built to use in Figma, they often feel like they're designed for web accessibility specialists or developers, not designers.

For example, to use most accessibility annotation tools, you usually need to know technical implementation details, like:

• HTML elements
• Semantic landmarks and roles
• Standardised autocomplete values
• WAI-ARIA attributes and roles

If you're a designer, it's unlikely your knowledge on HTML semantics or WAI-ARIA will be as good as the developer who you're handing over to. So, trying to annotate these things in your design can feel quite daunting!

An easier way to annotate your designs

Behaviours and expected outcomes

In software development, it's common to build and test things using a methodology called behaviour driven development (BDD). If you're not familiar with it, the idea is that you create tests for a computer to carry out, but written in a way where they also make sense to any humans reading them.

BDD describes the needs of the people using the application, then outlines possible scenarios. This way, when the application is built, it behaves as expected.

Scenarios may vary slightly in their format, but they're usually recognisable because of the words "given", "when" and "then". This is often referred to as Gherkin syntax, made popular by the testing framework Cucumber.

For example:

Feature: Sign in
    As a registered user
    I want to be able to sign in to my account
    So that I can view my account information
    
    Scenario:
        Given I am on the sign in page
        When I enter my username and password correctly
        And I click the sign in button
        Then I should navigate to my account

The point of BDD and the frameworks which enable it, is that it helps to facilitate collaboration between multi-disciplinary teams, which likely have a mix of technical and non-technical roles.

Using the same language

In user experience (UX) design, whether designing interactions or conducting usability tests, designers observe and anticipate user behaviour all the time. So, if designers are thinking about behaviours, and developers and testers are also thinking about behaviours, then it makes sense for us all to just use the same language!

As designers, using a similar format is an easy way to write up expected outcomes for accessibility, without needing to know the technical implementation to actually achieve it.

You might not need a "given" statement, because the design you're annotating probably sets the scene, but using the following pattern, you can quickly set expectations for developers:

When: describe action and context
Then: describe expected outcome

For example:

When I focus the pencil icon using a screen reader Then it should announce edit address

You can also use a table if there are a few different outcomes. For example:

When I enter a postcode And the format is invalid Then it should show the correct error message

Examples

Below is a set of examples showing how to use this method to annotate different elements in your designs.

Content structure

Ambiguous buttons

When I focus the hamburger button using a screen reader Then it should announce navigation menu

Ambiguous links

When I focus the read more link using a screen reader Then it should announce the visible read more label And it should also announce the associated blog post title

Heading levels

When I navigate the headings using screen reader Then it should announce the correct heading levels

Ambiguous unordered lists

When I focus the action menu using a screen reader Then it should announce that it's a list with four items

Ambiguous ordered lists

When I navigate the history timeline Then it should announce it's an ordered list with five items

Error suggestions

When I enter an invalid email And I submit the sign-up form Then it should show the error variant And the correct error message should be displayed

Keyboard functionality

Focus order

When I navigate the dialog using a keyboard Then the focus order should follow the correct sequence

1. Close button
2. Cancel button
3. Delete button

Focus styles

When I focus the delete button using a keyboard Then the focus variant should be visible

Skip links

When I navigate the page using a keyboard Then the skip link should be the first element to receive focus

Keystrokes

When I re-order the drag-and-drop sortable list using a keyboard Then it should respond to the following keystrokes:

Layout

When I zoom in my browser And there is not enough room for the navigation links Then the navigation menu should switch to the mobile variant

Multimedia alternatives

When I select the audio descriptions button Then the video should switch to the audio described version

When I select the closed captions button Then the captions should be turned on And they should be in sync with the video

When I select the transcript link Then the transcript side-panel should open And the transcript should be scrollable

Multimedia assets can be found at the following links:

Page titles

When I view the page tab in my browser Then it should show the correct page title

Reading order

When I navigate the main page content using a screen reader Then it should announce content in the correct order

1. Blog post content
2. Related posts
3. Sign up to our mailing list

States

Error identification

When I make a mistake in a text input And I am using a screen reader Then it should announce there's an error And it should show the error variant

Disabled

When I focus the button using a screen reader And it's in a disabled state Then it should announce that it's disabled

Loading

When I select load more search results using a screen reader Then it should announce the correct status updates

Expanding and collapsing

When I focus the disclosure element using a screen reader Then it should announce it's visible label And it should announce whether it's expanded or collapsed

Text descriptions

Images

When I focus images using a screen reader Then it should announce the correct text description

Icons

When I focus icons using a screen reader Then it should announce the correct text description

Timings

Durations

When I receive a new message Then then it should show the toast message "New message received!" And after five seconds it should disappear automatically

Time limits

When I am using a screen reader But I have not moved my mouse or pressed a key for twenty minutes Then the session timeout modal should appear And it should announce you're about to be signed out And it should announce the remaining time at the correct intervals

Final thoughts

Designing isn’t just about visuals; it’s also about creating the experience and the outcomes people should have.

You don’t need to annotate every single element. That would quickly get tedious! Annotate only elements that impact someone’s ability to navigate, perceive, or understand the interface, especially if those impacts aren’t obvious just by looking at the design.

You also don't need to learn or write perfect Gherkin syntax. But, if you just make it clear that, "when I do this thing, then I expect this to happen", it's already a lot more familiar. By using consistent language to describe designs and focusing on outcomes, you can clearly express design intent while leaving technical implementation to developers.

Further reading

• Accessibility Foundations
• Design patterns and WCAG
• Gherkin Reference Documentation

Next steps

For more information about accessible design, read about Accessible Design Systems or find out about how our design review service can help you identify design issues in your websites, mobile applications, design systems, and other products and services.

Her workspace may be dotted with half-finished craft projects and a stack of well-loved books, but no matter if she’s testing a new design or writing image descriptions, Catriona brings the same thoughtful precision and creativity.

Catriona is an Accessibility Specialist at TetraLogical, where she focuses on accessibility assessments and testing. She helps organisations meet the Web Content Accessibility Guidelines (WCAG) 2.2 and beyond, ensuring digital products are not only compliant but genuinely usable.

She holds an MSc in Publishing (Interactive Media) and is certified in Full Stack Web Development. Combining content and code, she helps teams think inclusively at every stage.

Before joining TetraLogical, Catriona worked at Jadu, auditing public sector websites, design systems, and web platforms. She supported teams with accessibility reviews, resources, and training, to embed accessibility into everyday processes.

Her journey into accessibility began in publishing, where she spent two years in the HarperCollins eBooks team before spending her next five years at Bloomsbury Publishing. Starting from a love of books and interactive media, she led eBook accessibility, integrating inclusive practices into workflows through training and guidance. She also established accessibility working groups, developed role-specific guidelines, and prepared the business for the European Accessibility Act. Her specialisms, image descriptions and accessible layouts, combine her passion for storytelling with her problem-solving mindset.

When she’s not working, Catriona is a proud hobby-dabbler. A classically trained pianist (currently restarting lessons, inspired by her musical colleagues), she also loves hiking, wild swimming, and weekend adventures in the Scottish Highlands.

She once took three months off to road trip around New Zealand in a van, which turned out to be a brilliant combination of travel, hiking, and Lord of the Rings fandom.

At heart, she’s a lover of stories, whether found in books, story-driven games, or a good TV binge. For Catriona, accessibility is about ensuring everyone has the right to enjoy stories too, whether through audiobooks, e-readers, or inclusive design.

What’s the one thing you wish you’d known when you started learning about accessibility?

That you don’t have to be an expert to start! The WCAG and WAI-ARIA documentation can seem overwhelming at first, and it’s natural to feel a sense of pressure that you should know it all before you can start. Yet, one thing I’ve learned since joining dedicated accessibility teams is that both experts and beginners still have the same discussions on how to interpret a specific success criterion or what is the most accessible way of designing a certain pattern.

With constantly evolving technologies and standards, accessibility is a continuous learning process. Stay curious, keep learning and don't be afraid to ask questions. There are many excellent high-level resources out there, such as our accessibility foundations blog post series, and a welcoming community who are all trying to make experiences more inclusive, regardless of knowledge level. As long as you continue to care and learn about the barriers people face, you’ll be well on your way in the journey to accessibility!

What’s your top accessibility tip?

Always keep the people who use your products in mind.

When you're deep in the technical specifications, it’s easy to focus on meeting all the success criteria and forget about the real people on the other end. Meeting WCAG is just the beginning of inclusive design practice. You can build something that is technically compliant without actually considering the needs of real people. Accessibility is nuanced; often, there’s more than one way to design an accessible pattern, and by focusing on certain success criteria, you may end up underserving people with different disabilities. Aim to go beyond and not assume, reach out for help and be open-minded to feedback.

Vice versa, as an auditor, it’s also important to remember that the WCAG standards have been interpreted into international legislation across the world. If we are auditing specifically against WCAG 2.2 Level AA then it is important not to fail something just because we don’t like it! Know the standards, but always advocate for the most inclusive solution.

What’s your top accessibility resource?

There are so many brilliant resources out there! Beyond the WCAG 2.2 Understanding Docs and MDN Web Docs accessibility documentation, I’ve come across so much rich knowledge just from exploring the a11y webring project, where accessibility experts share insights that go beyond the standards, addressing real-world implications and practical challenges.

However, some of my favourite resources come from our very own brilliant TetraLogical team members. When I’m in need for some real-world examples and clarity on the more “hand-wavy” success criteria, I constantly refer back to the talk These (still) aren’t the Success Criteria you’re looking for from Patrick H. Lauke and the TGPi quizzes from Ian Lloyd, especially When I Get That Low Contrast Feeling, I Need Non-Textual Healing; just remember to turn the sounds off if you don’t want to give the people around you a fright!

Find out more about TetraLogical, the team, our principles and our community.

Why inclusive language matters

Inclusive language fosters psychological safety by ensuring that people feel seen, respected, and valued through the words an organisation chooses. It enhances clarity by avoiding jargon, stereotypes, or assumptions about identity that can cause confusion or exclusion.

When everyone across an organisation communicates inclusively, it builds consistency and trust and becomes the way the organisation as a whole chooses to talk and work together.

Documentation

Start by ensuring your documentation reflects inclusive standards. An internal inclusive language guide provides a shared point of reference and can evolve alongside your organisation.

It can provide guidance on topics such as using person-first language, such as “a person with a disability,” while also recognising that identity-first language, such as “disabled person,” may be preferred by some communities.

It can also guide writers toward neutral alternatives, like “chairperson” instead of “chairman", encourage clarity by avoiding idioms or jargon that not everyone will understand and provide nuanced examples of the language relating to different communities. For example, “Deaf person” with a capital D when referring to members of the Deaf community, rather than “hearing impaired”.

Avoid a negative bias when talking or writing about disability. Phrases such as "suffers from", "wheelchair-bound", or "confined to" all imply a level of discomfort and hopelessness. Instead, use language that respects disabled people as active individuals with control over their own lives. For example, "someone who is blind", "person with a mental health condition", or "wheelchair-user".

By embedding these practices into editorial guidance, you set expectations that shape how all content is created and how team members communicate with one another.

Build into tools & content workflows

Inclusive language should not stop at documents; it needs to be reflected in the tools and interfaces people use every day.

Internal systems and customer-facing platforms should default to a respectful, neutral tone. For example, error messages should explain what has gone wrong without placing blame. For example, “Something went wrong” is far more inclusive than “You did something wrong" or "user error". Better still, include an error message that explains how to correct the error in plain language as shown in the following example.

Forms should allow for non-binary and diverse options where gender or pronouns are requested. Gender fields, for example, should allow people to self-describe rather than forcing a binary choice. If your form does not allow for text fields, consider offering the option of "Prefer not to say".

Sensitive data should only be collected when there is a clear and necessary reason, and always with an explanation of why it is required and how it will be used, while providing the option not to disclose.

Workflows should also embed checks for language in reviews, just as you would check for accuracy or accessibility issues. Adding inclusive language to content reviews, code reviews, and design approvals ensures that respectful communication becomes routine, rather than relying on individuals to notice problems.

Communication

Language is central to how teams interact, and inclusive communication should be a visible part of team culture. Encouraging people to share their pronouns and ensuring names and preferences are respected sets an open atmosphere.

When someone says they prefer “Deaf person” instead of “hearing impaired", for example, respecting that choice demonstrates that you value identity and autonomy and don't presume to know better than someone else's lived experience.

Providing training and resources equips teams with the tools to recognise when language may be non-inclusive. For example, pointing out that “wheelchair-bound” is stigmatising, and suggesting “wheelchair user” instead, helps people make better choices in future and avoids reinforcing stereotypes.

Inclusive language should also be introduced as part of onboarding so that new staff understand from the start what is expected of them. When leaders also model inclusive language in their own interactions, it signals that this is not optional behaviour but part of the organisation’s values.

Summary

Inclusive language isn’t just a gesture — it is an indicator of how much an organisation, and the people within it, value clarity, respect, and belonging.

When it is embedded into documentation, built into tools and workflows, and modelled in everyday communication, it becomes a natural part of the way people work together.

This shapes your teams, offers a supportive, safe working environment and makes it far more likely you will have a happy workforce who feel valued, included, and respected.

Further reading

• GOV.UK's Guidance on inclusive language: words to use and avoid when writing about disability
• ADA Factsheet: Guidelines for Writing About People With Disabilities
• The Inclusive Design Principles
• Understanding Success Criterion 3.1.3: Unusual Words - W3C

Next steps

For more information about the Web Content Accessibility Guidelines, read our WCAG primer or find out more about how our assessments can help you identify issues in your websites, mobile applications, design systems, and other products and services.

Designed to fit around busy schedules and real-world project work, the courses are created by internal accessibility specialists and informed by lived experience of disability. They can be accessed through TetraLogical’s own fully accessible learning platform or delivered via an organisation’s own LMS.

The courses form part of TetraLogical’s broader commitment to sustainable and inclusive digital practice. With a strong focus on learning in the flow of work, they are intended to support long-term capability-building, not just short-term compliance.

Practical, accessible, and built for real teams

TetraLogical’s self-led courses provide structured, practical learning across key accessibility topics. Learners move at their own pace and can return to materials as needed, making the courses ideal for:

• Onboarding new team members consistently
• Upskilling designers, developers, content teams and more
• Supporting hybrid and distributed teams across locations
• Reinforcing specific topics as part of wider accessibility programmes

All content is designed using learning experience design (LXD) principles to accommodate a wide range of learning styles, needs, and roles. The courses include text, video, images, quizzes, and reflection exercises, fully accessible and inclusive by default.

Supporting long-term change

The courses exist to address a common challenge for organisations: how to embed accessibility skills without disrupting delivery. The courses also aim to build organisational capability and promote consistency across teams, helping new starters get up to speed quickly, and minimising knowledge gaps when team members join or move on.

Léonie Watson, Co-Founder at TetraLogical, said:

One of the most common concerns we hear from businesses looking to embed accessibility into their workflows is that they struggle to find time for training, especially when they’re already stretched. Our self-led courses are designed to work with that reality, not against it. They’re flexible, accessible, and focused on helping people apply accessibility in their everyday roles, and are created to be low-cost and repeatable.

The intention of each course is to build confidence by helping teams apply what they’ve learned in real scenarios, whether that’s designing interfaces, writing content, or testing code. Our goal is to make accessibility something people feel equipped to do every day, even when deadlines are tight and resources are limited. That’s where lasting change happens.

The courses form part of a wider learning offering from TetraLogical, with a series of blended training programmes set to launch later this year. More information about the self-led training courses.

ENDS

Applying inclusive best practices when designing digital products results not only in more accessible products but also in more sustainable ones.

One of TetraLogical's founding principles is Ethical:

We make decisions for the good of our customers and their customers, our team, and for the world at large.

We also strive to be Sustainable:

We work collaboratively and efficiently to amplify enduring accessibility.

As part of our commitment to being ethical and sustainable, we are constantly looking for long-lasting solutions to reduce our environmental impact for the good of the planet. We are glad to find that more and more of our customers share our dedication to sustainability. While we are not experts on the subject, we can still contribute to their sustainability goals by helping them create inclusive products. This is because inclusive digital products are often green products.

Using the Inclusive Design Principles to build green digital products

When considering digital products and sustainability, many people think of the environmental costs of building, using, and dismantling hardware or the footprint of inefficient code. Few realise the huge impact that design choices can have on the carbon emissions of websites and mobile apps.

The Inclusive Design Principles (IDP) are a set of seven high-level principles that can help create truly inclusive experiences by considering the needs and preferences of all people. As this post illustrates, these principles can also help build greener products.

Here is an overview of how applying each principle can help you reduce your carbon emissions.

Principle 1: Provide comparable experience

Provide comparable experience: Ensure your interface provides a comparable experience for all so people can accomplish tasks in a way that suits their needs without undermining the quality of the content.

The first Inclusive Design Principle invites designers to think about comparable alternatives to content that may not be accessible to all. For example, people who are blind or have a slow Internet connection may not be able to see or load images; people who are Deaf or are in a noisy environment without headphones may not be able to hear audio content. To provide an equitable experience in these two scenarios, provide an alternative, comparable format such as an accurate text descriptions for images or a comprehensive text transcript for audio content. The same applies to documents such as PDFs, animations, and other multimedia content.

A similar requirement is in the Web Sustainable Guidelines being currently developed by the World Wide Web Consortium (W3C). Being larger in size, media content and some downloadable files require a larger amount of energy to load and transmit compared to text-based content. When a text alternative is available, many people may decide to access the alternative instead of playing the multimedia content or downloading the large document. By providing a comparable alternative you will not only ensure everybody has access to information, you'll also potentially reduce your website's carbon footprint.

Principle 2: Consider situation

Consider situation: People use your interface in different situations. Make sure your interface delivers a valuable experience to people regardless of their circumstances.

People are likely to access your digital products on a wide variety of devices and in a variety of situations. For example using a laptop while sitting at a desk, using their smartphone outdoors, or using a smart speaker while cooking.

When designing digital products, ensure they work well across devices, Operating Systems (OSs), screen sizes, and even without a screen!

This greatly helps people with disabilities who may need to use a specific device, assistive technology, or a specific orientation. It also helps reduce e-waste; when products don't work well across all devices (especially older devices) people are forced to replace them, which results in unnecessary and harmful landfill. Furthermore, devices with smaller or no screens consume less energy, which again reduces carbon emissions.

Principle 3: Be consistent

Be consistent: Use familiar conventions and apply them consistently.

Consistency makes digital products easier to use for everybody. When User Interface (UI) components use consistent visuals, labels, and locations people can find and operate them with ease.

Consistency is particularly important for people with permanent, temporary, and situational thinking disabilities, such as people with a brain injury or a migraine.

Better User Experience (UX) generally means less time spent on your website or app, as people are able to complete tasks quicker. The positive environmental impact of this is lower energy consumption. Using existing components, for example from an accessible design system or component library, reduces organisations' carbon emissions as developers won't use additional energy (and time) to write new code. The code of well-established components is also likely to be tidier and more efficient.

Principle 4: Give control

Give control: Ensure people are in control. People should be able to access and interact with content in their preferred way.

Inclusive products support people using assistive technologies and adaptive strategies. Some people may need to navigate a website using a screen reader for example, some may prefer to use a mobile app with an external keyboard, some may choose to customise the way content is displayed.

Other than working well with a wide variety of assistive technologies and input devices (as discussed under Principle 2: Consider situation above), your products must support OSs' and browsers' customisation options. Things like dark themes, larger text, reduced animation, and so on.

Customisation support is a key concept of inclusion - you cannot predict how someone may like or need to access your content, hence your content must adapt and adjust as required.

It can also help you reach your sustainability goals. Many of the customisation options available in OSs and browsers consume less energy than the standard content display. For example, animations can be quite large and require a considerable amount of energy to play. By ensuring your animations pause when reduced motion (or a similar option) is selected in a device's settings, you lower your content's carbon footprint. Similarly, researches have shown that using dark themes in devices with an OLED display has a positive impact on the environment.

Principle 5: Offer choice

Offer choice: Consider providing different ways for people to complete tasks, especially those that are complex or non standard.

People like to do things differently. For example, some people like to use a mouse, others a keyboard, and others voice commands. Some people may find using a search functionality the easiest way to find information on a website, others may prefer to use the navigation menu.

When possible, design alternative ways to complete tasks. This will improve the user experience for many people.

Some of these alternative ways of completing actions may also result in a lower energy consumption. If your service can be accessed both on a visual device (such as a laptop) and on a screenless device (such as a smart speaker), some people will choose to use the screenless device which consumes less energy. If your website contains both a navigation menu and a search functionality, some will use search and find information faster and with less page loading, again consuming less energy overall.

Principle 6: Prioritise content

Prioritise content: Help users focus on core tasks, features, and information by prioritising them within the content and layout.

With so much content on the screen, it is sometimes difficult to focus on the task at hand. This is particularly true for some people with thinking disabilities, such people with ADHD. This is why prioritising content is so important.

When designing pages, prioritise key information and components; decorative images and animations, ads, and other unnecessary content should be limited as much as possible.

A simplified design helps people who may struggle to focus and complete tasks otherwise. It also makes it easier for everybody to understand and find the information and functionality available on a website or app.

Less time spent looking for information or completing a task means less energy used. A clean design also means less data to load, especially when free of heavy media files and animations.

Principle 7: Add value

Add value: Consider the value of features and how they improve the experience for different users.

The last Inclusive Design Principle is all about identifying and using features that can improve people's experience on your website or app.

As mentioned earlier, better UX reduces the amount of time spent trying to complete tasks, which in turn reduces carbon emissions.

As an example, a simple feature you can include when designing a login form is the "Show password" button. This can prevent many people from submitting an incorrect password and having to re-fill the form. Such a simple solution improves the experience for your users and reduces the environmental impact of your website by avoiding unnecessary form reloads.

Summary

Applying inclusive best practices can help you design products that are better for the people and for the planet.

• Design text-based alternatives for rich media content
• Ensure your products work well across all devices (older and new), OSs, and screen sizes
• Use well-known UI components consistently
• Support OSs and browsers' customisation options
• Design alternative ways to complete tasks
• Avoid or limit unnecessary content
• Include features that can help people complete tasks more efficiently

Further reading

Here are some resources on digital sustainability you may find interesting:

• Web Sustainability Guidelines (WSG)
• Handbook of Sustainable Design of Digital Services
• The Hidden Carbon Footprint of Your Website: A Guide to Sustainable Web Practices

Next steps

For more information on how we can help you create inclusive products, visit our Services page or contact us at hello@tetralogical.com.

By removing unnecessary barriers at each stage of the hiring process, you will create fair, respectful, and effective processes. In turn, this expands the talent pool, strengthening your company's culture and demonstrating a genuine commitment to inclusion.

You should ensure that each stage of your recruitment considers candidates from a range of backgrounds and disabilities and does not unintentionally exclude any particular group.

Job adverts

This is your first opportunity to set the tone and demonstrate your commitment as a company that cares about accessibility.

Always write text with your users in mind. Use plain, inclusive language, avoiding metaphors or jargon that may be confusing. For example, say "You’ll work to tight deadlines and adapt quickly to changes" rather than "fast-paced environment”.

Opt for the active voice where possible, where the subject of the sentence performs the action of the verb. This makes the sentence direct, clear and concise. For example, say "you will lead a small design team" rather than "a small design team will be led by the successful candidate".

Test content with your target audience before publishing a job advert. Ideally, these should be people from varied demographics who are not already familiar with the job itself.

Essential skills should be clearly distinguished from desirable ones so candidates can make informed decisions about their eligibility.

It can be beneficial to highlight inclusive policies such as flexibility in hours, location, and the availability of reasonable adjustments. Always provide a link to your accessibility, Diversity, Equality, and Inclusion (DEI), or reasonable adjustments policies. It may also be worth including a statement encouraging applications from candidates with disabilities and neurodivergence.

Job adverts should be published in accessible HTML where possible. Avoid using PDFs or images.

Application process

Ensure you are transparent and clear throughout the entire process.

If you are able, accept applications in multiple formats, including accessible PDFs, Word documents, and video CVs. Ensure each one is treated equally.

If you are using recruitment software, request an Accessibility Conformance Report (ACR) or other accessibility statement. It is beneficial to test the application process using different assistive technologies and adaptive strategies. You can also use our Quick accessibility tests playlist as a starting point.

When designing online forms and the application process, break tasks into smaller, logical steps with clear instructions. Ensure you have clearly outlined the steps involved, with estimated times and a visible progress indicator. Avoid timeouts that may disadvantage candidates, and allow progress to be saved and resumed later.

Interviews

The primary point of an interview is to better understand the candidate, so ensure they are comfortable and treated fairly throughout.

This can be achieved by giving candidates advance notice of the interview format, length, panel members, and example questions. It is best practice to avoid surprise tasks; if tasks are included, explain whether they require preparation.

Base tasks and assessments on real-world examples rather than abstract challenges. This helps neurodivergent candidates in particular by providing clear, relevant context that reduces ambiguity and cognitive load, allowing candidates to focus on demonstrating their actual skills.

Avoid timed tests where possible, as this may disadvantage candidates who need extra time to process information or use assistive technology.

For remote interviews, choose an accessible platform and provide services such as captioning or sign language interpretation. Give candidates clear, easy-to-follow joining instructions. For in-person interviews, make sure the building is physically accessible and interpreters are available if needed. In all cases, offer any reasonable accommodations well in advance so candidates have time to prepare.

Take the time to train your interviewers in inclusive practices, unconscious bias, and disability awareness.

Communication

Throughout the process, you should provide a named point of contact for questions. This ensures a consistent source for information and support, reducing uncertainty and making it easier for candidates to ask questions or request adjustments confidently.

Let candidates know well in advance about any adjustments you can provide, such as breaks, assistive technology, or the option to bring notes, so they can prepare and take full advantage of them.

Use accessible formats for all communication, including emails and attachments and offer respectful, constructive feedback where possible.

Onboarding

Once you have chosen your preferred candidate, you can ensure a smooth transition from an accessible hiring process to an inclusive workplace.

Provide people with information in advance about their first day, what is expected of them, and what technology will be provided to them.

Be transparent about how their data will be stored, used, and kept confidential, particularly any personal, health, or disability-related information.

Ensure your onboarding materials, IT systems, software, and training materials are accessible from day one and implement the agreed-upon accommodations immediately.

Summary

Accessible recruitment means designing every stage of the hiring process so all candidates can demonstrate their skills fully and fairly.

From clear, inclusive job adverts to flexible application formats, thoughtful interview practices, and accessible communication, each step should remove unnecessary barriers and reflect a genuine commitment to equality.

This approach not only widens the talent pool but also ensures the best person is chosen for the role, creating a positive start for new hires and strengthening organisational culture.

Further reading

• Building a culture of accessibility
• Recruitment support services
• Introduction to Accessibility Conformance Reports
• UK Equality Act 2010 — legal obligations for accessibility and non-discrimination in recruitment.
• General Data Regulation Protection - your legal commitment to safe storage of data

Next steps

Our Recruitment Support service can help you design and deliver an inclusive process from the first interaction, from reviewing job adverts to training interviewers, and ensuring onboarding is accessible.

Except that retail websites are rarely accessible enough to make purchasing clothes much more than an exercise in “buy six things and return five". This isn't necessarily because the websites themselves are inaccessible, in the sense of being able to search for products, find out a little about them, add them to your basket or checkout, though that's not uncommon. It's that even the most accessible retail websites don't provide enough information to let you confidently make a choice, unless you can see the product images that is.

Let's take an example from a UK high street retailer:

Long sleeve Knitted jumper Crew neck It comes in black 100% Cotton.

You might think that's an adequate description, but if I were to ask you if the jumper is plain or ribbed, or if it falls to the hips or thighs in length, or if it's lightweight or chunky, could you tell me?

A different UK retailer does a bit better:

Crafted from soft pure merino wool, this jumper is a luxurious addition to your knitwear collection. It's crafted to a relaxed fit for endless layering options. A flattering v-neckline keeps things stylish, while cosy long sleeves with ribbed trims add a neat finish to this timeless piece.

But even so, what does relaxed mean, is it a deep V-neck, is the rib trim just on the sleeves or around the neck and/or bottom too?

Enter AI

Artificial Intelligence (AI) tools that can generate image descriptions are helpful in this context. My screen reader now has a feature that lets me request an image description from ChatGPT or Claude without having to switch contexts to do it.

There's no denying the fact that the people responsible for these websites should do a much better job of providing useful text descriptions, but we've been having that conversation for 30 years now, so forgive me if my patience is running a little thin!

There's also no denying the egregious theft of data and consumption of natural resources by AI platforms, and I've made my feelings on that clear elsewhere.

Using AI for image descriptions comes with a risk of hallucinations, but the consequences of falling for a hallucinated description don't put me at any more of a disadvantage than having no text descriptions at all. It's essentially a judgement call.

It's also not a great experience. It depends on the retailer putting the images where my screen reader can find them, or those images having enough of a text description to help me narrow down the choice of which images to query using AI, and on the content of the images themselves of course. Even under the best of circumstances, all of this takes time. A lot of time in fact.

Enter agentic AI

So, what if there was a different way? What if I could ask a digital personal shopping assistant to help me find clothes based on my preferred parameters? What if I could ask the assistant for product descriptions, then have a conversation with it to find out more, before letting the assistant know which one I'd like to purchase?

You may not know that this is already possible. It's still nascent technology, but it exists, and it's being used today to improve the accessibility and usability of the retail shopping experience.

An example is Innosearch, an AI ecommerce platform available in the USA, Canada, and the UK. It lets you shop from 500,000 online stores including those where I found the products mentioned above. Talking of which, it turns out that the long sleeved crew-neck jumper I found is for men... a minor detail that isn't obvious (if you use a screen reader) on the retailer's own product page!

In addition to presenting all products in a consistent and more accessible way than the websites they originated from, Innosearch automatically pulls out information that I'd otherwise have to actively look for - details only available in images for example. That isn't the interesting thing though. Innosearch has an agentic AI called CoBrowse, that goes beyond the behaviour of a typical AI chatbot.

If you're not familiar with the term "agentic", it refers to something that has agency, meaning it's capable of acting in its own right. Agentic AI is therefore a form of AI that can take actions on your behalf, as well as answer questions like a chatbot.

In this context, it means you can ask CoBrowse to search for a particular product. When I say "ask", I mean just that - you can enable your microphone and converse with it if typing isn't convenient. From there, it's a lot like having an actual personal shopping assistant in a bricks and mortar store. You can ask it to filter out results based on specific product features, exclude certain stores from the results, and once you've found a product, you can choose a size and ask it to add it to your basket, to open your basket, then add a coupon code or change the quantity of the last item to 3. One thing it can't do is complete checkout on your behalf, which is a reasonable limitation for security reasons.

Exit websites?

What all this really has me wondering, is why bother with a website? I don't mean the Innosearch website, I mean any retail website and, really, any website at all?

And, if you think this is a solution in need of a problem, then I'll wager you don't depend on the keyboard or use an assistive technology, that you've never been overwhelmed by the sheer quantity of information on a website, or been made nauseous or actually sick by constantly moving content, that you have good enough technology and connectivity to download vast quantities of JavaScript and other junk content without it affecting your ability to browse. I could go on, but you get the idea.

We humans love convenience and we dislike effort. We preferred the Graphical user Interface with its visual cues and affordances because it was more convenient than memorising countless command line instructions; we prefer the tap/swipe interaction of touch screen devices because it takes less effort than using a mouse/trackpad; and we generally prefer to have a chat because (for many of us) it requires no effort at all - and what could be more convenient than that!

No, I'm not going to predict the end of the web as we know it, but I do think there's a high probability that the way we use the web will change significantly - it's already changing in fact.

In July 2025, OpenAI revealed that ChatGPt users send about 2.5 billion prompts a day. That pales in comparison to the estimated 14 billion search requests Google handles each day, but when you consider that in December 2024 OpenAI reported the number as about 1 billion prompts a day, it's hard to deny that AI use is on the rise.

A recent report found that Google's AI search is reducing traffic to websites, in some cases by as much as 50%. Presumably AI platforms like Innosearch are doing the same thing, albeit at a far lesser scale, but what happens as more people discover that shopping with an agentic AI is much more convenient, or when Google uses AI to field all 14 billion of those search requests?

Whether we like it or not, and I confess I haven't yet made-up my mind, AI is almost certainly here to stay. The last time I remember a hype-cycle like this, it was the late 90s and what became known as the Dot-com Bubble. Yes, that bubble burst and the same will probably happen with AI, but what seems likely to remain is an agentic web of some kind.

And accessibility?

We're already being approached by organisations that are pivoting towards the agentic web and asking us what it means for accessibility. If they replace their websites with agentics that generate the information someone wants in the format they prefer, will that help or hinder accessibility? More to the point, how do we determine with reasonable confidence that the generated content is accessible? Anyone who's used the likes of Meta, Gemini, Claude, or ChatGPt for more than 10 minutes will know that you don't get the same response twice even when you repeat the exact same prompt, so where does that leave the concept of representative sampling, and how can we be sure our digital products meet our legal obligations?

His home office comprises of several laptops, about 30 pairs of artfully arranged trainers, and two giant fluffy cats to lend a supportive paw on every team call.

Craig Abbott is a Principal Accessibility Specialist at TetraLogical, where he focuses on embedding accessibility into organisational policies, processes, and culture. With a deep commitment to sustainable accessibility, Craig helps organisations scale their efforts beyond compliance, ensuring accessibility is built in from the start, not bolted on at the end.

Before joining TetraLogical, Craig was Head of Accessibility at the UK’s Department for Work and Pensions (DWP), one of the largest government departments. There, he established a dedicated accessibility practice and led the department’s accessibility strategy. His work focused on compliance, education, and culture change, transforming policies and empowering teams to sustainably deliver accessible services. Among his many achievements, Craig created the DWP Accessibility Manual and open-sourced the first versions to support others across the public sector.

Craig’s journey into accessibility is particularly unconventional. An early fascination with computers led him to tinker with Locomotive BASIC on an old Amstrad CPC 664 and later learn HTML, CSS, and JavaScript to customise his MySpace page. He expected to pursue a career in computer science. But traditional education didn’t suit his learning style; something he later understood was linked to undiagnosed ADHD and autism. Instead, Craig took a detour into engineering, spending his early career fixing buses.

Far from being wasted time, Craig credits his years as a mechanic with teaching him persistence and problem-solving

That mindset served him well when he pivoted into the digital world, first through freelance web and graphic design, then at a scrappy startup where he wore many hats, from frontend developer to customer support.

Craig entered the Civil Service in 2015 as an Interaction Designer and discovered accessibility through a Government Digital Service (GDS) Academy session with Alistair Duggin. He found himself excited to learn how to make things work for more people but also ashamed of how much inaccessible content he'd probably built previously. He quickly became the go-to person for accessibility in his department, running talks, workshops, clinics, and eventually building an entire accessibility practice.

Craig later joined Elastic, an open-source AI search company, as Design Manager and Accessibility Lead for enterprise cybersecurity software before coming to TetraLogical to work alongside lots of colleagues he'd met previously once he ventured into accessibility.

Outside of work, Craig is a passionate wildlife photographer with a particular fondness for birds of prey. He takes regular trips to Scotland to photograph white-tailed sea eagles and ospreys. He’s also a regular on the conference circuit, having spoken at events including Accessibility Scotland, AxeCon, UX London, Frontend North, and Access Given.

What’s the one thing you wish you’d known when you started learning about accessibility?

That most accessibility issues are introduced during the design phase. People often think WCAG is all about code and testing, but design decisions—like font styling, headings, colour contrast, or the use of drag-and-drop interactions—have a massive impact.

Designers are often closest to users, and known for their empathy. We should lead by example. If we make our designs accessible from the outset, there’s less risk they’ll become inaccessible during development. But if the design isn’t accessible, there’s no chance the final product will be.

What’s your top accessibility tip?

There’s no such thing as “100% accessible.” What works for one person may not work for another. WCAG 2.2 AA is a baseline, not a guarantee of usability. You can meet every checkpoint and still exclude people through poor language, jargon, or design patterns.

Accessibility is about people, not checklists. Most legal challenges come from complaints, not failed audits. If you test with real users—including those with disabilities, you’ll know whether your product is actually usable. Compliance is important, but usability is everything.

What’s your top accessibility resource?

I don't know if I could pick just one!

For design, I think it’s good to have guiding principles. Tools and books will go out of date, but principles which underpin what we do should move with the times:

• Inclusive Design Principles by Henny Swan, Ian Pouncey, Heydon Pickering and Leonie Watson
• Principles of Web Accessibility by Heydon Pickering

For development, I really like PolyPane. It helps you catch lots of bugs early on, with tools that let you:

• View multiple viewports at the same time
• Emulate things like dark mode, contrast and reduce-motion easily
• Highlight missing meta data
• Check accessibility by selecting colours, viewing focus order, headings and hidden content

For testing, I love a bunch of A11y tools by our very own Lloydi. I love that they’re powerful, yet uncomplicated. I don’t have to run a page scan from DevTools, or sign-up to a mailing list, they’re just there when I need them. They include:

• Isolator
• Show focus styles
• Element inspector
• Lost focus alert

Find out more about TetraLogical, the team, our principles and our community.

AT are tools that support people with disabilities in accomplishing tasks that might otherwise be difficult or impossible. These tools can take the form of software, hardware, or a combination of both, such as screen readers, magnifiers, speech recognition software, browser adjustments, adaptive keyboards, head pointers, switches, and eye-tracking devices.

According to the World Health Organization:

...most people will need assistive technology at some point in their lives, especially as they age. While some may require assistive technology temporarily, such as after an accident or illness, others may require it for a longer period or throughout their lifespan.

Assistive technologies

AT bridges the gap between a person’s abilities and the tasks they want or need to do. It removes barriers and opens doors to greater independence, inclusion, and opportunity. For many, these tools are not just helpful, they are essential. They enable full participation in education, employment, daily routines, and social life, ensuring that everyone has a fair chance to connect with the world around them.

Adaptive strategies

Not all disabilities require specialised devices. Sometimes, adjustments, known as adaptive strategies, are all that’s needed to support access and engagement. These might include turning on captions, enlarging text, or customising display settings. Whether through high-tech solutions or everyday adaptations, the goal remains the same; to support autonomy, dignity, and equal access for all.

AT and strategies by disability group

There’s often a narrow assumption that AT only refers to tools like screen readers. While screen readers are indeed essential for people who are blind or have low vision, they don’t support the needs of everyone. For example, someone with a hearing disability wouldn’t benefit from a screen reader, but might rely on captioning tools or visual alerts instead. Different disabilities require different types of AT and adaptive strategies, and in this section, we’ll explore the range of tools used by people with different types of disability to support access, communication, and participation.

People often use a combination of assistive technologies and adaptive strategies, which may change depending on the task or context. Whilst this list highlights some commonly used tools, it represents only a portion of the AT that exist, the field continues to grow, offering a wide and evolving range of innovative solutions.

Seeing

People with seeing disabilities refers to disabilities related to vision, which affect a person's ability to see.

Screen readers

A screen reader is a software application that converts digital text on a screen into synthesised speech, enabling people to access and interact with digital content non-visually. Common examples include JAWS, NVDA, and VoiceOver. Screen readers are essential tools for people who are blind or have low vision, allowing them to navigate their devices and engage with content through audio feedback.

Braille displays

A braille display is a tactile device that works in conjunction with a screen reader to convert on-screen text into braille. It uses a series of small, refreshable pins that rise and fall to form braille characters, enabling people who are blind to read digital content through touch. Braille displays offer real-time access to text; however, these devices are often expensive, making them financially inaccessible for many people.

Screen magnifiers

A screen magnifier is a software tool that enlarges the content displayed on a screen, making it easier to see for people with low vision. It allows people to zoom in on content, and often includes features like colour contrast adjustments and focus tracking to enhance visibility and reduce eye strain.

Smart glasses

Smart glasses that can appear as regular glasses with clear lenses, or sunglasses are categorised as a wearable. These devices use cameras, audio output, and sometimes Artificial Intelligence (AI) to provide real-time information about the environment. For people who are blind or have low vision, smart glasses can assist with tasks like reading text aloud, identifying objects or people, recognising scenes, and navigating unfamiliar spaces. Some models, like Envision Glasses or OrCam MyEye, are specifically designed as assistive tools, while others, like Ray-Ban Meta Smart Glasses, can be adapted with AI apps to offer helpful visual information through audio feedback. One of our directors, Léonie Watson, writes about her experience using the Ray Ban Meta smart glasses here.

Keyboard shortcuts

Browsing with a keyboard and using key combinations allows people who are blind or have low vision to quickly navigate and perform tasks without relying on a mouse or touchpad. Keyboard shortcuts offer an efficient, non-visual method of navigating digital interfaces. By reducing the need to locate icons or menu items visually, keyboard shortcuts provide a faster, more consistent way to access functions, especially when used in combination with screen readers or memorised navigation patterns.

High contrast mode

High contrast mode is a visual display setting that enhances the distinction between foreground and background colours to improve readability. It often uses bright text, such as white or yellow, on a dark background, or the reverse, to make text and interface elements easier to see. This mode is especially helpful for individuals with low vision, glare sensitivity, or colour perception difficulties, as it reduces visual clutter and highlights key content more clearly.

Hearing

People with hearing disabilities refers to disabilities related to hearing, which affect a person's ability to hear.

A note on Deaf and deaf: Capitalised Deaf refers to the cultural identity and shared experiences of the Deaf community. Lowercase deaf describes the physical condition of hearing loss.

Hearing aids

Hearing aids are small electronic devices worn in or behind the ear that amplify sound. They help people with hearing loss hear speech and environmental sounds more clearly by making them louder and more focused.

Cochlear implants

Cochlear implants are surgically implanted devices that bypass damaged parts of the ear to directly stimulate the auditory nerve. They provide a sense of sound for people with severe or profound hearing loss who get limited benefits from hearing aids.

Real-time captioning

Communication Access Real-Time Translation (CART) provides live, human-generated captions for spoken content. It’s often used in classrooms, meetings, or events to make spoken information accessible for people who are Deaf or hard of hearing.

Captions or subtitles by default

Watching videos or TV with captions or subtitles is a common strategy to ensure access to spoken content. Many people enable captions by default, whether watching online videos, attending webinars, or streaming entertainment.

Speech-to-text apps

Speech-to-text apps convert spoken words into written text in real time using voice recognition technology. They are useful in everyday conversations, meetings, or phone calls, providing visual access to spoken content.

Written communication

Many people who are Deaf or hard of hearing choose to communicate through written channels like email, text messaging, or chat apps. This strategy avoids the barriers of phone or voice communication and allows for clear, accessible, and asynchronous conversations. Furthermore, modern text messaging has its roots in early text-based tools like the teletypewriter (TTY), which was developed to enable Deaf individuals to communicate with both Deaf and hearing people.

Moving

People with moving disabilities refers to disabilities related to moving, which affect a person's ability to perform physical tasks.

Eye-tracking devices

Eye-tracking devices allow people to control a computer or communication system using only their eye movements. These tools track where a person is looking and translate that into actions like moving a cursor, selecting buttons, or typing text which is useful for individuals with limited or no hand movement.

Switch controls

Switch controls are customisable input devices that let people interact with technology through simple, repeated movements, like pressing a button, puffing into a tube, or tapping their head. They are often used with scanning software to navigate menus or type text, one selection at a time.

Speech recognition software

Browsing with speech recognition allows people to operate devices through spoken commands. Programs like Dragon NaturallySpeaking lets people dictate text, move the cursor, open applications, and browse the web without using their hands which is ideal for people with limited mobility or repetitive strain injuries.

Keyboard shortcuts

Many people browse with a keyboard instead of a mouse to reduce the number of physical movements required. Some also remap keys to easier-to-reach locations or use external programmable keypads for quick access to frequent actions.

Customising the user interface

People may customise user interfaces (UI) to reduce complexity, such as pinning essential apps to the home screen, increasing icon size, or using simplified launcher apps, which minimise the number of taps, clicks, or movements needed to navigate.

Thinking

People with thinking disabilities refers to disabilities related to neurodivergence, which affect a person's ability to process information, communicate and interact socially.

Text-to-speech (TTS)

TTS tools like Natural Reader, Voice Dream Reader, or built-in features on phones and computers read written text aloud. This supports people who have difficulty reading, processing, or comprehending written language.

Speech-to-text and voice dictation

Tools like Google Voice Typing or Dragon NaturallySpeaking convert spoken words into text. These are useful for people who struggle with typing, writing, or spelling.

Reading support

Apps like Immersive Reader (by Microsoft) help people by simplifying text, highlighting words as they're read aloud, and offering picture supports or definitions.

Password managers

Tools like 1Password simplify logins and reduce cognitive load by securely storing and auto filling saved passwords.

Alarms and timers

Using alarms and timers as external memory aids is a way to offload the mental burden of remembering when to do something or how long to do it for some people with thinking disabilities. For example, a person with ADHD may set a 25 minute timer to stay focused on a task, followed by a 5 minute break. This is known as the Pomodoro technique.

Browser extensions or reader modes

For many people with thinking disabilities, such as ADHD, or dyslexia, reading content online can be overwhelming due to cluttered layouts, flashing ads, and inconsistent formatting. A helpful adaptive strategy is using browser tools like reader mode, which simplifies pages by removing distractions and showing only clean text and images, or ad blockers which hide pop-ups and autoplay videos to support focus and limit distraction.

Next steps

Read more accessibility foundations posts or sign up for Accessibility Unlocked, our free six-day newsletter series designed to help you kick-start accessibility.

This post provides information on the application of the EAA in the context of websites and mobile apps.

Understanding any new legislation can be challenging. The nature of the European Accessibility Act as a directive and its wide scope can make it particularly difficult to fully understand.

While our Understanding the European Accessibility Act (EAA) post provides a review of the entire directive, this post focuses on digital content only, to make it easier for organisations offering websites, mobile apps, and other digital content to find the information they need.

What is the difference between a directive and a law?

The EAA is a directive, not a law. It sets the overall goals that organisations must achieve, but it does not contain details about how these goals are enforced and monitored. This is decided at a national level by each European Union (EU) member state.

Over the past few years, all EU member states have transposed the EAA into national law. Organisations operating in EU markets must comply with the relevant national law in order to comply with the EAA.

Does the EAA apply to my organisation's websites and apps?

This depends on many factors, including the size of your organisation, the countries it operates in, and the types of digital services it offers.

The following decision tree may help you understand whether your organisation's websites and apps are covered by the EAA:

1. Does your organisation have 10 employees or more AND an annual turnover of 2 million Euros or more?
2. Does your organisation operate in EU markets?
3. Do the digital services your organisation offers fall into any of the following categories?
   • Digital communication services: communication apps like Zoom and WhatsApp
   • TV and video streaming services: platforms like Netflix and YouTube
   • Transport services: websites and apps to book or access air, rail, bus, or water transport
   • Financial services: consumer banking websites and apps
   • Digital books and reading applications: eBooks and eBook reading apps
   • E-commerce platforms: consumer facing marketplaces such as Amazon and eBay

If you answered Yes to all of these questions, the EAA most likely applies to your organisation's digital services.

Even if your organisation does not provide services directly to customers but sell web or native content to other organisations that make it available to the public, it still needs to consider the requirements of the EAA. Unless its content is compliant, organisations covered by the EAA may be unable to purchase or integrate it into their services.

What are the requirements my organisation needs to meet?

There are three sets of requirements your organisation need to consider:

• The general requirements that apply to all digital services, as described in the EAA
• The additional service-specific requirements, also set out in the EAA
• The country-specific requirements, outlined in national law

The general requirements your organisation must meet are set in the EU "harmonised standard" EN 301 549 (PDF). According to the EN 301 549, digital services must meet WCAG 2.1 compliance. Note that this is due to be updated to reference WCAG 2.2 soon.

Your organisation must then check whether the services it provides are subject to the additional service-specific requirements described in Annex I Section IV of the EAA. For example, one of the requirements in the EAA for consumer banking services is:

Ensuring that the information is understandable, without exceeding a level of complexity superior to level B2 (upper intermediate) of the Council of Europe’s Common European Framework of Reference for Languages.

Finally, organisations must comply with the country-specific requirements in the national law of the countries they operate in.

Does all web content need to comply with the EAA?

No, the EAA lists a number of exemptions:

• Pre-recorded time-based media published before 28 June 2025;
• Office file formats published before 28 June 2025;
• Online maps and mapping services, if essential information is provided in an accessible digital manner for maps intended for navigational use;
• Third-party content that is neither funded, developed by, or under the control of, the economic operator concerned;
• Content of websites and mobile applications qualifying as archives, meaning that they only contain content that is not updated or edited after 28 June 2025.

The EAA also contains a section about disproportionate burden; if an organisation believes that making some of its content compliant would result in a disproportionate burden, it can request for it to be exempt. However, very few cases are likely to meet the criteria for disproportionate burden. For example, a small organisation offering self-help eBooks might qualify if the cost of full compliance would genuinely threaten its ability to operate. A larger company with greater resources, however, is unlikely to meet that threshold.

How can my organisation reach compliance?

The steps that organisations should take as they work towards reaching compliance are described in another EU harmonised standard referenced by the EAA: EN 17161 Design for All

As described in Understanding EN 17161 Design for All, this standard explains how organisations can integrate accessibility in their processes and practices across the following areas:

• Context of the organisation
• Leadership
• Planning
• Support
• Operation
• Performance evaluation
• Improvement

How is compliance with the EAA monitored?

Monitoring compliance is responsibility of the individual EU member states. Each state has its own monitoring processes and has appointed one or more market surveillance authorities to carry them out.

The market surveillance authorities are ultimately responsible for ensuring that organisations operating in their country follow the EU harmonised standards EN 301 549 and EN 17161 and any additional country-specific requirements, thus complying with the EAA requirements.

They are also tasked with reviewing the applications for disproportionate burden claims.

How can my organisation document compliance?

Your organisation's websites and apps must be assessed against WCAG and their compliance level must be described in a publicly available accessibility statement.

Currently, the EAA does not provide details on the contents or format of this statement. However, in 2022 the European Commission (EC) requested the harmonised standard EN 301 549 be updated and part of this update will be to include "a model accessibility statement in accordance with Directive (EU) 2016/2102". Many organisations are therefore already using the model accessibility statement template from Directive (EU) 2016/2102 to document the compliance level of their digital services.

Article 13 of the EAA also requires organisations to inform the relevant market surveillance authorities of non-compliant services:

In the case of non-conformity, service providers shall take the corrective measures necessary to bring the service into conformity with the applicable accessibility requirements. Furthermore, where the service is not compliant with applicable accessibility requirements, service providers shall immediately inform the competent national authorities of the member states in which the service is provided, to that effect, giving details, in particular, of the non-compliance and of any corrective measures taken.

Since each member state is ultimately responsible for monitoring conformance, your organisation should also check any country-specific requirements around documenting compliance.

What are the consequences of non-compliance?

The penalties for non-compliance are set by the individual EU member states; they may include fines or prohibition on selling services altogether.

According to Article 13 of the EAA, if you are contacted by a market surveillance authority you must:

Provide it with all information necessary to demonstrate the conformity of the service with the applicable accessibility requirements. [You] shall cooperate with that authority, at the request of that authority, on any action taken to bring the service into compliance with those requirements.

Based on this, it is likely that market surveillance authorities will first ask organisations to rectify any existing issues and make their services compliant. However, if issues are not acted upon promptly, organisations are likely to face penalties.

Next steps

To learn more about the EEA and associated standards, you can read our Understanding the European Accessibility Act (EAA) and Understanding EN 17161 Design for All posts. We can also provide EAA assessments and sustainable accessibility support to help you meet your goals.

Current HTML support tables

So far, we’ve published the following support tables. These are works in progress, and we’re continuing to add others, including combinations such as TalkBack and iOS:

• JAWS HTML support in progress but safe to use
• NVDA HTML support in progress but safe to use

Background to the HTML support tables

Since the start of my accessibility work in 2001 I have had an interest in how screen reader software supports the semantics of HTML elements. I was initially taken by an article (now lost in the interwebs, I have looked, but nowhere to be found) which provided information about how JAWS supported various HTML 4 elements. This interest led me into creating the HTML Accessibility API mappings in 2010 and working on it until editing was taken over solely by Scott O'hara.

By “support”, I mean how HTML elements are communicated to people using the software. For example, how are headings announced? Can people navigate to them easily? What level of interaction is possible? These questions help us understand how well screen readers and other tools support different HTML elements.

I don't know about you, but even though I have used various screen readers as part of my accessibility testing work for many years, I still forget what keystrokes can be used to interact with elements. The HTML support tables help with this as they provide keyboard interaction information for HTML elements.

How we document HTML support

As an example, the data for the <abbr> element from the JAWS and NVDA support tables is reproduced below together with an explanation of what data is documented in each column:

• Element: name of the HTML element linked to the HTML spec definition of the element
• Test Case: link to the test case used
• Represents: Short description of what the element represents
• Aural UI: What is announced when a person using JAWS or NVDA interacts with the element.
• Interaction: Ways in which the content can be navigated to and interacted with
• Supported: if and how the screen reader supports the element semantics
• Notes: further information

Further reading

• HTML Accessibility API mappings
• Core Accessibility API Mappings 1.2

Next steps

Information about our Assessment service or browse our accessibility foundations posts.

How did you get to where you are?

My first degree was in Creative Writing and English Literature. At the time I was a poet and very focussed on my writing. One of my lecturers published my final project, Lost and Found, and I got paid £0.00 for it. I thought then it may be best to find something more lucrative. Since I was a writer, I wanted to build a website to showcase all my writing in one place, however I couldn't afford to pay anyone to build it for me, so I decided to learn HTML. I then discovered Ruby where I really fell in love with coding.

I did a Ruby bootcamp and then dove into the tech industry. I've worked in various areas such as web development, software engineering, tech support, web advocacy and more. In that time I also ran a non-profit, blackgirl.tech, with the aim of getting more black girls, women, and non-binary people into coding.

I got into standards through my job at Samsung Internet where I was responsible for advising the Samsung Internet Engineering team on which privacy standards were on the horizon and which standards the team be looking to adopt into the Samsung Internet browser. I went on to lead the Web Platform Program at Bocoup which is where I learnt about accessibility standards and resources (as well as a bunch of other stuff) through the ARIA-AT program.

I'm still an artist, although not writing as much anymore, and I'm always trying to find ways to bring the two together; I document what I do on https://lolaslab.co.

What motivated you to run for the TAG (W3C Technical Architecture Group)?

Initially I didn't think I was in the stage in my career to run, so I didn't actually consider it, however, a couple of members of the W3C TAG (Technical Architecture Group) reached out to me separately asking if I'd consider it. I enjoy working in standards, this is a part of my job where I genuinely feel like I'm making positive, meaningful contributions and working on TAG is an opportunity to increase the impact I make in the community. I care first and foremost about web users, and I wanted the opportunity to continue to develop and contribute to the work that actively prioritises them with documents like Societal Impact Questionnaire, PDF, the Ethical Web Principles, and more.

What are your priorities and plans for working on the TAG?

I recently became the co-editor of the Societal Impact Questionnaire Working Group with my colleagues Sarven and Tristan, so that's a priority for me. I want to help the W3C think about ways we can be more considerate about the social implications of the technology we create.

I'm also interested in developer education and demystifying the standards process, so I've started a podcast called What the Spec?! where I unpack web standards and browsers with the people who create them.

I've started contributing Web Platform Tests in the accessibility area, as I think this is a really good way to gain a deeper understanding in how specs are implemented in browsers. I also think it'll make me better at reviewing specifications.

My biggest priority is conducting design reviews of incoming specifications. TAG reviews spec proposals as part of our work and most recently I've been paying close attention to privacy-focussed specifications, particularly those which aim to replace a function of third-party cookies, and specifications which may have some kind of impact on accessibility.

Do you feel that your first degree being in the humanities gives you a different viewpoint?

Yes. I think it gives me a human-centred perspective, which often balances out technical abstraction with real-world impact. I approach standards work thinking about how it affects people's lives, not just code or systems.

Why did you start blackgirl.tech?

Before I began to learn how to code after my first degree, I didn't know being a software engineer or web developer was an option for me. We didn't do coding in my ICT classes in secondary school. I was also often times the only black person or black woman in many of the technical rooms I was in. I wanted black girls to know that if they want to, they can use code to build things online, and I wanted to to give them the skills to do that. Initially it wasn't about jobs or a career in tech, it was more about making digital creations.

What was the most rewarding and the most challenging thing about running blackgirl.tech?

The most rewarding thing was the internship program I ran in the last year of blackgirl.tech. We were able to get two women from our community onto a paid 3 month training program which then led to an 18 month internship program with the agency 8th Light. Originally the training was unpaid with only one place, but it was important to me that if folks were going to be in full time training, they have a way to sustain themselves, even if the training is free. Once 8th Light saw how many applicants there were, they decided to take on two people.

The most challenging part was the racism and misogyny in the industry. When you're running a program for marginalised people, those outside the marginalised group think that by helping you, they're doing you a favour. Or they want to use you to sanitise their image in some way.

What barriers do under-represented groups face in web standards?

I think the biggest ones are financial backing and being unaware that web standards and the W3C exists. When I speak to folks from under-represented backgrounds about the work I do in standards, many of them don't realise that the W3C produces more than WCAG. So I think there's an outreach/marketing thing there. But also, of the those who do know about the W3C, they can't afford to join.

In 2021 I was co-chair of the developer council and one of our aims was to reach out to folks from underrepresented backgrounds to participate in web standards. I was working with a task force, all folks from various parts of the web however, only myself and the other co-chair, Boaz Sender were funded, which meant the others couldn't participate as much as they would have liked. Eventually we had to stop the work (for a few reasons also) because it wasn't sustainable.

Tell us more about your work on automated testing of screen reader support for web standards

At Bocoup, I was the Web Platform Program Lead and one of the projects I was looking after was AT-Driver, a specification which details a protocol to allow remote testing of screen-readers.

When I joined the AT-Driver was still being developed in the ARIA Community Group and wasn't on the standards track, and while there was some buy-in from some assistive tech vendors, there were others who were concerned about various security issues. I essentially had to do some campaigning for the project, as well as make decisions about how to prioritise incoming issues. I led the chartering of the project in the Browser Tools and Testing Working Group, which is the first step to getting the spec on the standards track. This means that BTT commits to producing the specification and giving time to the project.

AT-Driver is currently being used in the ARIA-AT project to run tests for the patterns listed in the ARIA Authoring Practices Guide. AT-Driver is heavily influenced by WebDriver BiDi so it's a very low level technology, the idea is that others will build on top of it, to create testing libraries for screen-readers that can remotely access the screen-reader in a test environment. Mike Pennisi is the current editor and lead engineer on the project, and Meta (specifically Matt King) is also providing direction and funding for the project.

More from Lola

• Lola on Wikipedia
• Improving Accessibility with ARIA-AT: A Web Standards Case Study - video

Next steps

For more information about TetraLogical's W3C activities, read Our Impact

Both are harmonised standards used by the EAA and yet all the focus has been on EN 301 549. This post explores how the two standards relate to each other, and what that means for providers of digital products and services.

In brief

As outlined in Understanding the EAA by Léonie Watson, we interpret the EAA's requirements for digital products and services to mean that economic operators and service providers should take the following steps to maximise their conformance with the Act:

• Use EN 17161 Design for All to put in place processes and practices that enable continuing conformance with the accessibility requirements
• Use EN 301 549 and the functional performance criteria in Annex I to demonstrate conformance with the accessibility requirements
• Document how services conform to the accessibility requirements, and how processes and monitoring help achieve conformance
• If warranted, carry out a disproportionate burden assessment, and report to all national authorities where the product or service is available if an exemption is claimed

For the purposes of this post, we will refer to EN 17161 Design for All, as Design for All.

Availability

Design for All is a paid for standard available from a number of places at a range of prices.

Purpose

The purpose of Design for All is to help organisations embed accessibility into their management systems, ensuring that accessibility is considered from strategy and planning through to implementation and review.

Scope

Design for All is applicable to all organisations regardless of type, size or sector. It supports making products, goods, services, and environments accessible and usable by as many people as possible, including disabled and older people.

Key points

Focus

Design for All is a framework of process requirements that complements EN 301 549, the technical standard referenced in the EAA. As such it emphasises how to integrate accessibility considerations into seven areas which are outlined in clauses 4 to 10:

• Context of the organisation
• Leadership
• Planning
• Support
• Operation
• Performance evaluation
• Improvement

User involvement

Design for All has a strong emphasis on the importance of involving a diverse range of people, particularly people with disabilities, in the design and evaluation process.

This is covered in detail in Annex C where it describes including people with disabilities in the design process in the following ways:

1. Understand who will use it and how

Understand who your audience is and in what situations they'll be using the product or service.

2. Learn what users need and want

Get a clear picture of what matters to people, including their goals, preferences, abilities, and limitations, so these can shape the design and requirements.

3. Design something that works for them

Create solutions that match what people need and expect, based on what you've learned.

4. Check if it actually works for users

Test the solution with people to see if it meets their needs and works well for them, and check whether it matches the original goals.

Compatibility

The Design for All approach is intended to align with other management system standards such as ISO 9001, making it easier for organisations already following such frameworks to incorporate accessibility.

Supports compliance with the EEA

EN 17161 Design for All, is already a recognised standard that can be used to demonstrate conformance with the EAA. A revised version is planned for publication in September 2025.

Clauses and requirements

Clauses 4 to 10, describe areas an organisation can focus on in order to adopt the Design for All approach.

Clause 4: Design for All approach

The Design for All approach focuses on how organisations can embed accessibility into their operations. It sets the foundation for making accessibility a consistent part of strategy, design, and delivery, particularly in the context of digital and physical products, services, and environments.

Clause 4.1: Accessibility following a design for all approach

Design for All is about making products and services work for as many people as possible including older people, and different types of disability including people with seeing, hearing, moving, or thinking disabilities.

It means thinking about accessibility and usability from the very beginning, and keeping it in mind through every stage of the product or service lifecycle.

The Design for All approach doesn't mean everything has to be identical for everyone. It means making sure people can:

• Access it: find it and take it in
• Understand it: know what it's for and what to do
• Use it: take action or respond in their own way

In short, it's about flexibility, not uniformity, so everyone gets a comparable experience, in a way that works for them.

Clause 4.2: Understanding the organisation and it's context

Organisations should make sure that all relevant policies, processes, and activities follow a Design for All approach. To do this well, they need a clear understanding of how their internal and external environments affects accessibility.

This includes:

• User needs and preferences: what people require to access, understand, and use products and services
• Feedback on existing products and services: what people are telling you about barriers and improvements
• Legal and regulatory duties: national and international requirements for accessibility
• Competitor practices: how others in the sector are addressing accessibility
• Compatibility with assistive technologies: ensuring products work with tools people rely on
• Changes in technology: keeping pace with new platforms, devices, and trends
• Supply chain capability: what partners and suppliers can deliver in terms of accessibility
• Economic, social, and cultural factors: broader issues that shape how people engage with your organisation

Clause 4.3: Understanding the needs and expectations of interested parties

Organisations should identify who uses their products and services, who is excluded, and why.

Organisations should:

• Identify who uses the product: including those who use the product or service directly, and those who support others to use it
• Understand who is not using it: especially where accessibility may be a barrier
• Plan for inclusion: identify what needs to change to help more people access, understand, and use the product or service
• Consider delivery needs: take into account the needs of anyone involved in delivering or supporting the service
• Review regularly: keep this information up to date as things change

Clause 4.4: Determining the scope of the Design for All approach within the organisation

Organisations should decide how and where their Design for All approach will apply.

Organisations should consider:

• Internal and external factors: identified in Clause 4.2
• People's needs and expectations: described in Clause 4.3

Clause 4.5: Integration with established process systems

Design for All works best when it's part of everyday practice, not treated as an add-on. To make this happen, accessibility should be built into existing processes and systems.

Organisations should:

• Understand and address accessibility needs: make sure everyone knows what's required and why it matters
• Recognise the value of inclusion: help all teams see the benefit of reaching more people
• Embed accessibility into all processes: from design and development to delivery and support
• Use feedback and data: learn from real experiences to improve products and services over time

Clause 5: Leadership

Leaders play a critical role in making accessibility part of how an organisation works. They need to set the vision, define policies, assign responsibilities, and provide the support and resources needed. A strong, well communicated commitment from the top makes it more likely that accessibility will be built into every part of the organisation.

Clause 5.1: Leadership and commitment

Senior leaders in the organisation must show clear commitment to accessibility by creating an accessibility vision and goals to inspire employees and provide clear goals to measure progress against.

Leadership should show their commitment to accessibility by:

• Investing in accessibility: providing enough time, money, and people
• Setting clear goals: defining targets and how success will be measured
• Making responsibilities clear: assigning ownership across teams
• Embedding accessibility into culture: encouraging everyone, from planning and design to marketing to take part
• Creating space for innovation: supporting new ideas to improve accessibility and reach more people
• Supporting continuous improvement: reviewing progress and identifying areas to grow
• Monitoring activity: keeping track of design and development decisions
• Linking accessibility to brand and reputation: using accessibility as a way to build trust and reach more customers
• Building capability: identifying training needs and recruiting people with the right skills

Making accessibility happen takes both a top-down and bottom-up effort. Product teams can lead the way, but real impact depends on strong support from leadership. Senior decision makers play a critical role in setting direction, removing barriers, and making accessibility part of how things are done.

Clause 5.2: Policy

Leadership should create an accessibility policy that:

• Shows commitment: focuses on improving access, understanding, and use by people with disabilities
• Applies across the organisation: is scoped to be used across all teams, products, and services
• Drives continuous improvement: supports learning and progress over time
• Fits the organisation's purpose: is aligned with goals, values, and the business context
• Gets reviewed regularly: is updated when things change or new needs emerge
• Is shared openly: is understood by everyone inside the organisation, and outside, when relevant

Clause 5.3: Organisational roles, responsibilities and authorities

Leadership should clearly assign and communicate responsibility for accessibility by:

• Defining accountability: making it clear who is responsible for improving accessibility and reaching more users
• Checking effectiveness: making sure accessibility efforts are working as intended
• Keeping users in focus: ensuring all teams consider a wide range of user needs
• Building understanding: helping staff recognise the value of designing for different characteristics, abilities, and preferences

Clause 6: Planning

Planning for accessibility means thinking about risks, opportunities, goals, and changes. Organisations should set clear objectives, build accessibility into all relevant processes, and be ready to adapt while protecting accessibility outcomes. A planned, proactive approach ensures more people can use products and services effectively, now and in the future.

Clause 6.1: Actions to address risks and opportunities

When planning a Design for All approach, organisations should consider internal and external factors (clause 4.2) and user needs and expectations (clause 4.3) to:

• Support accessibility goals: make sure policies and processes can deliver what's needed
• Avoid problems: reduce the risk of missing user needs or accessibility targets
• Use opportunities: find ways to attract new users or explore new service areas
• Reach more people: keep expanding who can access, understand, and use products and services

Organisations should also:

• Plan specific actions: address risks and opportunities directly
• Embed actions into everyday work, including:
  • recruitment and hiring
  • disability knowledge and lived experience
  • user involvement and feedback
  • product and service design
  • manufacturing and delivery
  • work with external providers
  • packaging and presentation
• Evaluate impact: check how well actions are working
• Track barriers: collect and review information on what prevents people from accessing, understanding, or using the organisation's products and services

Clause 6.2: Design for All approach objectives and planning to achieve them

Organisations should set clear accessibility goals across relevant teams and levels that:

• Align with the vision and policy: reflect the organisation's purpose (clause 5.2)
• Are measurable: define clear outcomes where possible
• Meet requirements: cover both legal and organisational needs
• Are tracked and reviewed: checked regularly to monitor progress
• Are clearly communicated: shared across the whole organisation

To meet these goals, organisations should plan:

• What needs to happen: define the specific actions
• What resources are needed: identify time, money, and people
• Who is responsible: assign clear accountability
• When it will happen: set realistic timelines
• How success will be measured: agree what good looks like

Clause 6.3: Planning for changes

Organisations should plan for any changes that could affect accessibility or their Design for All approach. Changes to policies, processes, or activities must be managed carefully and with a clear plan (clauses 4.2 and 4.3).

When planning changes, organisations should:

• Understand the reason for change: know why it's needed and how it could affect people
• Assess the potential impact, including:
  • The overall Design for All approach
  • The accessibility of products and services
• Check available resources: identify what time, people, or budget will be needed
• Review roles and responsibilities: decide if any changes are needed in who does what

Clause 7: Support

Organisations need to put the right resources, skills, communication, and documentation in place to support their Design for All approach. This means making sure teams are informed, trained, and equipped. And that decisions and actions are clearly recorded and reviewed.

Clause 7.1: Resources

Organisations should provide the right resources to support a Design for All approach and meet accessibility goals. This means making sure the right people, tools, and systems are in place at every stage.

Organisations should:

• Review what's already in place: assess internal skills, tools, and infrastructure
• Identify what's missing: decide what support or expertise is needed from outside
• Make use of existing knowledge: identify and apply what's already known about accessibility and inclusion
• Support inclusive design infrastructure: build and maintain systems that make accessible ways of working possible
• Match resources to each stage: identify resources for design through to delivery and monitoring
• Fund measurement and tracking: allocate time and money to measure progress and impact

Clause 7.2: Competence

Organisations should make sure everyone involved in Design for All has the right knowledge, skills, and experience. This helps teams make informed decisions and deliver accessible outcomes.

Organisations should:

• Identify required skills: understand what capabilities are needed across roles
• Provide ongoing training: keep staff up to date with regular learning and development

Clause 7.3: Awareness

Everyone involved, including employees and suppliers, should understand their role in supporting a Design for All approach. Clear communication helps build shared responsibility and sustained progress.

Organisations should make sure people are aware of:

• The vision and policy: as set out in clause 5.2
• Accessibility objectives: defined in clause 6.2
• Their role and responsibilities: how they contribute to an inclusive culture
• Performance feedback: how well their work supports accessibility outcomes

Clause 7.4: Communication

Organisations should plan how they communicate about Design for All and accessibility, both internally and externally. Good communication builds awareness, accountability, and trust.

Organisations should:

• Decide what to share: choose the most relevant and useful information
• Plan when and how to share it: use the right timing and channels for each audience
• Identify who needs to know: make sure the right people receive the right messages

All communication should be clear and accessible.

Clause 7.5: Documented information

Organisations should create and maintain key documents that support their Design for All approach. These documents help track progress, guide decisions, and show accountability.

Organisations should include documentation that covers:

• Interested parties and their needs: who uses their products and services as outlined in Clause 4.3
• The scope of the approach: where and how Design for All applies (clause 4.4)
• The vision and policy: setting direction and intent (clause 5.2)
• Accessibility goals: what the organisation aims to achieve (clause 6.2)
• Supporting processes: systems in place to deliver on accessibility (clause 8.1)
• User needs in design: how people's requirements are included (clause 8.2.3)
• Accessibility evaluations: how accessible products and services are assessed (clause 8.2.5)
• Accessibility across the user journey: from start to finish (clause 8.4)
• Monitoring and measurement: how progress is tracked (clause 9.1)
• The assessment process: and the outcomes (clause 9.2)
• Decisions and actions for improvement: what's been done in response (clause 9.3)
• Updates and improvements: any changes made over time (clause 10)
• Other relevant documentation: anything else the organisation deems necessary

Clause 8: Operation

Accessibility needs to be part of every stage of a product or service, from design through to launch. Organisations should understand who their users are, include them early on, and think about their needs at each step. Testing, clear communication, and working closely with suppliers all help make sure the whole user journey is accessible.

Clause 8.1: Operation planning and control

Organisations should embed Design for All into everyday operations. This helps make accessibility a consistent part of how work gets done.

Organisations should:

• Set clear ways of working: define rules and expectations
• Check regularly for consistency: make sure teams follow agreed processes
• Manage change: plan for changes and respond to unexpected issues (clause 6.3)
• Hold suppliers to the same standard: ensure external partners meet accessibility requirements

Clause 8.2: Design and development of products and services

Clause 8.2.2: Identifying the intended users

Clause 8.2.2.1: Establishing users and non-users

Organisations should understand who can, and can't, use their products and services. This helps identify barriers and uncover opportunities to improve accessibility.

Organisations should:

• Identify who is and isn't using what they offer: including direct and indirect users
• Find out why some people are excluded: collect insights from those affected through user research, usability testing, and feedback loops
• Use multiple sources: look at internal data and external research
• Analyse the information: organise and curate insights and use them to fill any knowledge gaps

Clause 8.2.2.2: Specifying the intended users

Organisations must clearly define who the intended users are, making sure this includes the widest possible range of people, including those who access products indirectly for example through another person or device.

Clause 8.2.2.3: Identifying the needs, characteristics and capabilities of the intended users

Organisations must:

• Recognise diverse user needs: consider differences in age and physical, sensory, mental, and cognitive capabilities
• Identify the context of use: including location, environment, and typical tasks
• Understand the relationship between needs and context: how different environments and situations affect what people need from a product

Clause 8.2.3: Requirements to extend the range of users

Design specifications must include:

• User requirements: based on identified user needs
• Legal and regulatory requirements: including relevant laws and regulations
• Applicable standards and guidance: such as accessibility and usability standards
• Information on barriers and assistive technologies: to help reduce or remove barriers
• Compatibility with assistive technology: including interoperability considerations
• Insights from earlier analysis: drawing on findings from user research (clause 8.2.2)

Clause 8.2.4: Realisation

Clause 8.2.4.1: Developing solutions

Organisations should:

• Use reliable user information: based on evidence rather than assumptions
• Follow best practices: in accessibility and inclusive design
• Gather and apply user feedback: including feedback from people who use assistive technologies
• Use an iterative design process: test, improve, and repeat
• Ensure equal treatment: for people who use assistive technologies
• Maximise compatibility: by using open standards that support assistive technology

Clause 8.2.4.2: Approaches to design solutions to achieve accessibility outcomes

Designs should:

• Offer multiple ways to interact: so people can access and use content in different ways
• Support flexibility:so people can adjust the design to suit their needs
• Reduce complexity: by keeping interactions simple and avoiding unnecessary steps
• Enable personalisation: so people can tailor access to their needs
• Avoid unnecessary limits: that restrict how people interact with the product
• Be compatible with assistive technology: ensuring smooth use with a wide range of hardware and software

Clause 8.2.5: Evaluation

Organisations must evaluate their products and services to check they meet accessibility goals.

This includes reviewing:

• Early concepts: to identify issues from the start
• Prototypes: to test ideas before development progresses
• Technical specifications: to ensure accessibility is built into the foundations
• Design alignment: checking how well the product matches its intended design
• Usability testing with disabled people: to understand real-world accessibility

Testing and evaluation should take place during development and between product versions.

Clause 8.3: User involvement

Organisations must involve disabled people as early as possible in design and development.

This includes:

• Identifying user needs and preferences: to shape inclusive solutions from the start
• Gathering feedback on barriers and opportunities: to understand what helps or hinders access
• Identifying relevant assistive technologies: that people use to interact with products
• Involving users in testing and evaluation: to check how well the design works in practice

Clause 8.4: End-to-end chain in relation to accessibility

Organisations must think about accessibility across the whole user journey, not just the product itself. This means identifying:

• Where the biggest barriers exist: across different stages of the journey
• How mature each part is: in terms of accessibility readiness
• Who controls each stage: whether internal teams or external partners
• How external factors affect access: such as packaging, instructions, and customer support

Both internal and external factors should be reviewed, including:

• Pre-sale and purchase: how people find, choose, and buy the product
• Installation and setup: how easily the product can be put into use
• Post-sale support and warranty: how help and repairs are handled

The organisation must assess these factors and use the findings to support:

• Stakeholder needs: as outlined in clause 4.3
• Scope definition: as outlined in clause 4.4
• Planning and design: as outlined in 6.1, 6.2, and 8.2
• Evaluation and improvement: as outlined in 8.2.5, 9.1, and 9.2

Clause 8.5: Control of and communication with external suppliers

Organisations must set clear accessibility and usability requirements for suppliers and communicate:

• What is expected: outlining their responsibilities clearly
• How they contribute: to meeting end-to-end accessibility

This helps ensure that externally sourced products or services still support the organisation's accessibility vision and goals.

Clause 9: Performance evaluation

Organisations need to keep checking how well their Design for All approach is working. This includes measuring what's happening, listening to users, and tracking progress. Regular internal checks and reviews by leaders help make sure the organisation stays on track and makes products and services more accessible to more people over time.

Clause 9.1: Monitoring, measurement, analysis and evaluation

Clause 9.1.1: General

Organisations must regularly monitor, measure, analyse, and evaluate how well their Design for All approach is working.

This helps them check if they are:

• Meeting accessibility goals: by tracking progress against targets
• Following planned processes: to maintain consistency and quality
• Achieving intended results: by measuring impact on users

They must:

• Decide what to monitor and measure: linked to the organisation's policy (clause 5.2) and objectives (clause 6.2)
• Use reliable methods: to collect and assess meaningful data
• Check real-world access and use: whether products and services are being accessed, understood, and used by as many people as possible
• Evaluate effectiveness: using the results to assess how well the Design for All approach is working

Monitoring helps track whether more people are able to use a product or service and where improvements may be needed (clause 10).

Clause 9.1.2: User feedback

Organisations must collect feedback from users, including people with disabilities, to understand whether their needs are being met.

This includes:

• Involving a diverse group: especially people who may not usually take part
• Offering multiple feedback options: such as online, phone, or in-person
• Using feedback to improve: policies, processes, and products

Clause 9.1.3: Analysis and evaluation

Organisations must analyse the data they collect to:

• Show compliance: demonstrating that products and services meet Design for All requirements
• Improve customer satisfaction: by responding to real user experiences
• Assess effectiveness: checking how well the overall approach is working
• Review supplier performance: evaluating how well external partners are delivering
• Identify process improvements: finding areas that need change or refinement

The results from this analysis feed into management decision-making and help guide further actions.

Clause 9.2: Internal audit

Organisations must evaluate its own processes and systems regularly to check whether:

• Practices match policies: ensuring alignment with their own Design for All commitments
• Requirements are met: confirming compliance with this standard
• The approach is maintained: checking that it's being properly followed over time

They must:

• Share results with relevant managers: so findings are acted on
• Take corrective action: to fix problems and prevent them happening again

Clause 9.3: Management review

Senior leaders must regularly review:

• Design for All policy and goals: as set out in clauses 5.2 and 6.2
• Performance and audit results: including findings from evaluations and internal audits (clauses 9.1 and 9.2)

These reviews should cover:

• Progress on previous actions: tracking follow-up and results
• Relevant changes: both internal and external
• Effectiveness of the approach: how well Design for All is being applied
• Trends and indicators, such as:
  • Accessibility outcomes
  • User feedback
  • Supplier performance
  • Internal audit findings
• Opportunities for improvement: and how well risks and opportunities have been addressed

The review must lead to clear decisions and actions to improve accessibility and extend the range of users. Leadership is also responsible for ensuring the organisation has the resources needed to carry out these improvements.

Clause 10: Improvement

Organisations must treat accessibility as an ongoing effort. That means acting on feedback, checking progress, and always looking for better ways to meet users' needs. Improvements should be based on evidence and regularly checked for impact.

This means they must:

• Identify areas to improve: across processes, procedures, and activities
• Take action: to make those improvements
• Check the results: to see if the changes worked as expected

Improvements should be guided by:

• Management review outcomes: outlined in clause 9.3
• Accessibility goals and objectives: outlined in clause 6.2
• Performance evaluations: outlined in clause 9.1
• Internal audit results: outlined in clause 9.2
• Data analysis: that highlights problems or opportunities

As well as evaluating its performance against the Design for All approach (Clasue 9.2), organisations can also carry out assessment of products and services in order monitor progress and improvements.

Next steps

For more information, read Understanding the EAA by Léonie Watson or find out more about how our Agile Usability Testing service and Embedded Accessibility consultancy services can help you meet your EAA goals.

Being able to connect with people and earn their trust is key for user researchers. It makes participants feel at ease, not be afraid of giving their honest opinion, and enjoy the session. This ultimately leads to richer, more meaningful research insights.

In our post Moderating sessions, we discussed the importance of showing respect to participants. Other than being the right thing to do, showing respect also contributes to building a mutually beneficial relationship with the people taking part in the research.

This post explores additional ways to build rapport with participants.

In case you missed them, here are the other blog posts in our Inclusive user research series:

• Moderating sessions
• Analysing findings
• Recruiting participants

Show care

First and foremost, we want people to have an enjoyable experience and feel like they are making an important contribution. In other words, we want participants to know we care about them and we value their help.

There are a few ways you can do this.

Firstly, approach every interaction with participants with care, beginning with the very first email or phone call. Consider every exchange as an opportunity to show your appreciation for their participation.

Secondly, make sure they are able to join the research session with ease by providing any support they may need ahead of the session. This will remove any anxiety they may otherwise feel, improving the overall experience. For example, for in-person sessions you could share detailed instructions on how to reach the research venue, and offer to meet people at the train station or bus stop. For remote sessions, you could email them clear instructions on how to download, install, and use the video conferencing platform.

Protect personal information

As researchers, we often have access to some of participants' personal details, such as age, telephone number, email address, and so on. In the case of people with disabilities, we may also have information on medical conditions they have or assistive technology they use.

Some participants may feel nervous about sharing this type of information. By showing them you will handle their data with care following best practices, you can alleviate their concerns.

As part of the recruitment process, provide participants with clear information on the data protection policies you'll follow. When doing that, make sure to use the simplest language possible; too often information on data protection contains jargon and legal terms that many people, especially those with thinking disabilities, may struggle to understand.

Also, make it as easy as possible for participants to confirm their agreement with your terms and conditions. Signing a paper or digital document may be difficult for some; provide another way to do the same, such as simply stating their agreement in an email.

Finally, check with participants they have no questions or doubts about data privacy at the beginning of each session.

Compensate fairly

As we all know, time is valuable. Participants should be offered a fair compensation for their time.

Whether it is cash or a voucher, decide on a fair compensation and let participants know about it early on in the recruitment process.

Best practice is also to assure participants they will receive their compensation regardless of the session outcome, including if the session ends earlier than expected. People should feel comfortable asking for breaks if they need one, or requesting to end the session if they feel unwell, for example.

Limit activities

Trying to cover too many tasks and questions in a research session can be stressful for both you and the participant. It is important to limit the amount of content to cover in each session.

When planning your research sessions, ensure you allocate sufficient time to complete all tasks, address key questions, and allow space for clarifications and follow-up inquiries. Keep in mind that some people with disabilities may require more time to process and answer questions or complete activities; you don't want to rush them. People should feel they can take all the time they need, and request breaks if they feel tired or need to take medications, for example.

Limiting the amount of content in each research session also allows for a relaxed, slow-pace conversation, which can help build rapport. And at times, you may feel like diverting slightly from the script and engaging in a bit of informal chat, which can make the session more enjoyable.

Remember, in inclusive user research, less is often more.

Ask necessary information only

In all research projects, it's necessary to collect some participants' personal information, both at the recruitment stage and during the sessions. In addition to following best practices around data protection (as previously discussed), limit questions to what is necessary only.

For example, you may need to know the assistive technology that people use, but you don't necessarily need to ask about the medical conditions they have; in some cases, it may be useful to know how long people have been living with a disability, but there is no need to ask how they've acquired it.

Being asked lots of personal information, especially at the beginning of a research session, can feel intimidating. By limiting personal questions, we show participants that we respect their privacy, which can help them feel more at ease. As the session progresses, it is common for people to start opening up and volunteering information.

When writing recruitment criteria or a test script, always ask yourself whether a piece of information is truly needed to answer the research objectives. If not, leave it out.

Don’t generalise

When conducting research with people with disabilities, it’s tempting to assume that one participant’s experience reflects that of other people with similar disabilities. For example, one might assume that if content doesn’t work well for one screen reader user, it won’t be accessible to any screen reader users. But this is not always the case. People with the same disability or using the same assistive technology can have very different experiences with a product or service depending on many factors, such as personal preferences or the settings they use.

It's also important to avoid asking participants about other people. Questions like "Do you think this content will work well for other Deaf people?" or "Would all screen reader users be able to navigate and understand this content?" are not useful and may strain your relationship with participants; they may feel they are being categorised based on their disability rather than being valued as an individual.

Don’t make assumptions

Similarly, assumptions based on someone's disability fail to recognise the uniqueness of each participant.

While it may be common to assume that those who are blind don’t appreciate images, or that those who are Deaf don’t enjoy music, these kinds of assumptions are often incorrect and reflect a limited understanding of the diversity of people’s preferences and needs.

Rather than making assumptions, ask questions. No matter how trivial or obvious the question may seem to you, participants will likely be happy to answer and share their experiences. Asking questions is a way to demonstrate curiosity and a genuine interest in learning about others, which is often very well received.

Appreciate the value of people's feedback in every session

When running inclusive user research, no two sessions are the same.

People's disabilities and the adaptive strategies they use can greatly impact their experience with a product or service. Also, symptoms associated with some medical conditions can vary on a daily basis, which can also impact the way people interact with products.

For example, fibromyalgia symptoms can fluctuate and change significantly from day to day. This means that a participant with fibromyalgia may be able to use a mouse and focus on tasks with ease in one session, and really struggle to use a mouse and need many breaks in another session.

As a researcher, it is important that you recognise these variations as representative of people's real life, hence valuable insights. Make participants aware that you appreciate their input and feedback in every session. People should not feel they are failing the researcher on days when they don't need to use assistive technology, or guilty when they need more breaks or more time to complete activities.

Keep in mind that people observing sessions may not be accustomed to such variability in participants' conditions and behaviours. You may have had someone commenting that "the participant didn't appear to be disabled", just because the participant's symptoms happened to be mild on the day of the research. It is important to explain this variability to stakeholders, so they can also appreciate the value of all sessions.

React appropriately

Something that can seriously damage our rapport with participants is overreacting to their stories or comments.

People with disabilities often face challenges or experience painful or debilitating medical conditions. While it's important to show empathy when someone shares their experience, you should never express pity. Showing pity may imply that you regard participants as helpless, which can be disempowering.

At the same time, avoid praising people for completing ordinary tasks, such as cooking, travelling, or working. Again, that can come across as patronising and can significantly harm your relationship with participants.

Simply showing you understand the challenges people face and appreciate the strategies they've developed is an effective way to maintain a positive, constructive relationship.

Summary

When running inclusive user research, building rapport with participants is key. Some considerations that may help you establish a positive and constructive relationship include:

• Let participants know you value their help
• Make it as easy as possible for them to join the session
• Assure them you'll protect their personal details
• Provide a fair compensation for their time
• Limit the amount of activities in each session
• Only ask for the personal information you really need
• Never assume or generalise participants' experiences
• Show empathy but avoid pity and ableism

Next steps

Looking for some support as you develop your skills in inclusive user research? Read about our User Research Mentoring programme or find out more about our Agile Usability Testing service.

Keyboard accessibility ensures that people who navigate websites or apps using a keyboard, whether due to disability, injury, or personal preference, have an experience that is just as functional and efficient as those using a mouse, touch, or other input methods. While the interactions may differ, the goal is to provide equal usability and access to content. Prioritising semantic HTML and offering keyboard-friendly alternatives for complex interactions enhances the experience for all users.

Who benefits from keyboard accessibility?

Keyboard accessibility is essential for many people with different types of disability that may be permanent, temporary, or situational, or for people who prefer keyboard navigation:

• People browsing with a screen reader who cannot see or have low vision rely on keyboard navigation to move through content efficiently
• People with moving disabilities and limited dexterity may be unable to use a mouse and instead browse with a keyboard
• People with temporary injuries, like a broken wrist, repetitive strain injury, or a minor finger injury can find it difficult to use a mouse, highlighting the importance of keyboard support

By ensuring robust keyboard support, you create a more inclusive and user-friendly experience for everyone.

Where possible, use HTML

There may be situations where delivering an identical experience isn’t possible, so an equivalent experience must always be provided. For example, when exploring an interactive map, people with a mouse might click, drag, or scroll to move around. While these exact interactions may not translate directly to a keyboard, alternative navigation options, such as arrow-key navigation or keyboard-accessible buttons, can provide an equivalent experience.

When building accessible interfaces, start with semantic HTML. In line with the first rule of ARIA, HTML has already done most of the heavy lifting. While ARIA is a powerful tool for remediation, it should be a last resort. Many accessibility issues can be avoided simply by using the correct native elements.

One of the biggest advantages of semantic HTML is that it requires no extra effort for keyboard support. Native interactive elements, such as buttons (<button>) and links with a valid href (<a href="#">), come with built-in keyboard functionality, ensuring a more accessible experience without additional coding.

For example, compare these two buttons:

A native HTML button:

<button>I am a button</button>

• Uses the <button> element, which is inherently interactive with a keyboard
• Automatically supports keyboard interactions, for example pressing Enter or Space to activate
• Is focusable by default (no need for tabindex)
• Works with screen readers and assistive technology

A custom button:

<div role="button" tabindex="0">I am also a button</div>

• Requires role="button" so assistive tech recognises it as a button
• Needs tabindex="0" to be focusable
• JavaScript must be added to handle keyboard activation (Enter or Space), as <div> does not natively support it

If you can use native HTML, do it. It saves you and your team time, reduces the risk of accessibility failures, and ensures built-in support for keyboard navigation. However, there are instances where native HTML alone may not be enough.

When HTML alone isn't enough

Sometimes, native elements don’t fit the design or functional requirements, and a custom solution is needed. Examples include:

• Custom dropdowns, when <select> is too limited
• Modals or dialogs, beyond what <dialog> provides
• Complex interactive widgets, for example sortable lists, carousels, rich text editors

When creating custom components, you must follow the third rule of ARIA to ensure they remain accessible to keyboard users. This means handling focus properly, supporting keyboard interactions, and maintaining expected behaviours.

Common keyboard accessibility failures

Most common issues associated with the keyboard accessibility of custom controls can be avoided. Two instances that are seen regularly within accessibility assessments result in a failures against:

• 2.1.1 Keyboard (Level A)
• 2.4.3 Focus order (Level A).

Clickable controls without tabindex

A common issue is interactive elements that work with a mouse but aren’t accessible by keyboard. This often happens when <div> or <span> elements are used instead of native HTML interactive elements.

This is problematic because by default <div> and <span> elements are not focusable. Similarly, people cannot tab to them, making them completely inaccessible via keyboard. However, these issues can be avoided by following a few steps.

If you must use a <div> or <span> for styling reasons, make it keyboard accessible by:

• Adding a tabindex="0" to bring it into the focus order, for example <div role="button" tabindex="0">Click me</div>
• Using JavaScript to add keyboard support and event handlers, for example <div role="button" tabindex="0" onclick="doSomething()" onkeypress="handleKeyPress(event)">Click me</div>

However, using a real <button> is always the better solution.

Non-interactive elements receiving focus

Some developers try to improve accessibility by adding tabindex to non-interactive elements, thinking it will help screen reader users. However, this actually causes more issues than it solves. The motivation behind doing this is often an attempt to create a richer experience for screen reader users, coupled with a misunderstanding of the difference between keyboard and screen reader navigation. Interactive controls receive focus, not static text. So, when static text receives focus by virtue of tabindex values, it creates confusion for people who may believe they can interact with an element that is actually static. It disrupts expected navigation as keyboard users don’t expect to focus on static text.

A common issue arises when tabindex is applied to headings, causing focus order problems. Since non-interactive elements receive focus, they create unnecessary tab stops, disrupting the keyboard navigation experience.

For screen reader users, headings can already be navigated efficiently using built-in shortcuts. For example, when the screen reader NVDA is in browse mode, pressing H moves to the next heading (with its level announced), while Shift + H moves to the previous one. Because these elements are inherently accessible, forcing focus on them with tabindex is redundant.

Avoid using tabindex on non-interactive elements. Instead, structure content with proper headings, landmarks, and semantic elements to enhance navigation. Reserve tabindex only for custom interactive controls when necessary.

Summary

• Use native HTML whenever possible
• Ensure custom controls are keyboard focusable by adding tabindex="0"
• Ensure custom controls are interactive by adding JavaScript
• Avoid adding tabindex to non-interactive controls

Further reading

• 2.1.1 Keyboard (Level A)
• 2.4.3 Focus order (Level A)
• When to use tabindex=0, Graeme Coleman
• Keyboard accessibility myths and WCAG, Graeme Coleman
• Foundations: native versus custom components, Ela Gorla
• Understanding screen reader interaction modes, Léonie Watson
• The difference between keyboard and screen reader navigation, Léonie Watson

Next steps

Read more accessibility foundations posts or sign up for Accessibility Unlocked, our free six-day newsletter series designed to help you kick-start accessibility.

Many people rely on text descriptions, especially people who use screen readers. But, they’re often missing or poorly written. Given how widely AI is being used for writing content, we wanted to see how well an LLM can handle the task.

A good text description should help somebody to understand the image within the context of the surrounding text and why it was chosen. For example, if you had a photo of the Pyramids of Giza, you might describe it differently depending on where you use it.

On a:

• Travel blog, you might focus on the location, terrain and cultural significance
• History website, you might focus on the construction and historical background
• Photography portfolio, you might focus on the lighting, composition and mood

We wanted to see if an AI can do this. So, we put some of the most popular LLM to the test, asking them to describe images with and without additional context, to try and understand:

• Are AI-generated text descriptions good enough to use as they are?
• Can they at least provide a strong starting point for a human to edit later?
• Does providing additional context improve the quality of AI-generated text descriptions?

What we did

The LLM we tested

We set out to test the top five most popular LLM, which are:

• OpenAI, ChatGPT
• Anthropic, Claude
• Google Gemini
• Meta AI Llama
• Deepseek R1

However, we could not get Deepseek to process images, so we included a popular open-source LLM called Mini-CPM V instead.

Mini-CPM claims to have better image recognition abilities than ChatGPT, Claude and Gemini. With such a bold claim, it felt like an interesting one to include!

The prompts we used

We had the LLM describe each photo twice.

First, we provided the image on its own with no context, using the prompt:

Generate alternative text for this photo. Use plain language and 10 to 20 words to highlight the most important information for non-sighted people.

Then, we provided the image along with a paragraph to provide additional context, using the prompt:

Generate alternative text for this photo using the provided context. Use plain language and 10 to 20 words to highlight the most important information for non-sighted people. Provided context: "This line was replaced with a paragraph for context."

Before giving the images to the LLM, we removed any meta-data associated with the image file as we figured the LLM might read it and use it for clues. This is not necessarily a bad thing. For example, if it reads the location the photo was taken, then perhaps it might provide a better description. However, meta-data is never guaranteed to be in any photo, especially as a lot of tools and platforms strip it out when processing or uploading images. So, we chose to remove it.

The images we chose

Image 1: The "Friends Apartment" Building

I took this photo of my wife walking in front of the "Friends Apartment" on Bedford Street, in New York.

We chose it because it's a famous building that attracts thousands of tourists, yet it looks unassuming and reasonably generic.

We wanted to understand if the LLM could understand the cultural significance of the building or the location of it.

The additional context we provided to the LLM:

The image will be used on a fan website for "Friends", a popular American sitcom that aired from 1994 to 2004. Based in New York, it followed the lives and careers of six friends: Rachel, Ross, Monica, Chandler, Joey, and Phoebe. Friends is known for its witty humour, relatable characters, and iconic catchphrases. It quickly became a cultural phenomenon, influencing fashion, language, and sitcom storytelling. Decades after it finished, it remains one of the most rewatched series in television history.

Image 2: The Statue of Liberty Replica

I took this photo on a recent trip to Las Vegas in front of the New York-New York Hotel and Casino.

We chose this photo because the Statue of Liberty is one of the most instantly recognisable landmarks in the world. But, this isn't actually the Statue of Liberty.

We wanted to understand if the LLM could reason with what it found in the photo, such as the roller coaster, and come to the conclusion that this is not the actual Statue of Liberty.

The additional context we provided the LLM:

The image will be used on a travel website for "Las Vegas", a vibrant city famous for its huge casinos, luxury hotels, and themed attractions. The New York-New York Hotel and Casino stands out, with its striking replica of the New York City skyline, including the Statue of Liberty and the Brooklyn Bridge, which are intertwined with "The Big Apple" rollercoaster.

Image 3: The Gender Assumption

This stock image was listed as: "Young African-American transgender, smiling confident at street."

We chose this photo because it's important to use inclusive language when describing images, and this includes making appropriate choices about people's pronouns or gender.

The person in the photo is described as being transgender, but there are no specifics about how they identify. So, we wanted to understand if the historical data used to train the LLM would influence the language they choose or assumptions they make.

The additional context we provided the LLM:

The image will be used on a social media post to promote inclusive language and respect for people's pronouns, which is essential for fostering dignity, respect, and belonging. We should acknowledge peoples identities and reduce discrimination for transgender and non-binary people. Misgendering can cause harm. By using inclusive language in professional, educational, and social settings, we promote equity, ensuring everyone is seen and valued for who they are.

Image 4: The 3 Finger Salute

This stock image was listed as: "Protesters flash a three-finger-salute during the demonstration at the Democracy Monument."

This photo is from recent protests in Thailand, where people gathered at the Democracy Monument to demand change from their government. The three finger salute was taken from the Hunger Games, a book by Suzanne Collins. In the book, the salute is used as a gesture for revolution.

We chose this photo because without context, it's very difficult to understand what's going on. You can't see any facial expressions and the salute is very similar to other known gestures, like "the scouts promise".

The only real clue this is a protest is the sign being held up in the centre of the frame, which reads: "It is the music of a people who will not be slaves again."

We wanted to understand if the LLM could describe the image with enough context to make it meaningful. Can it understand the location, what is happening, or the mood of the people?

The additional context we provided the LLM:

The image will be used on a political blog. The three-finger salute, a symbol of revolution inspired by "The Hunger Games", became a powerful gesture during protests at the Democracy Monument in Thailand. It signifies defiance against authoritarian rule, unity among protesters, and a call for freedom, justice, and equality. Despite crackdowns, the salute remains an enduring emblem of resistance in Thailand’s fight for democracy.

Results and observations

Image 1

This is how each LLM described the Friends Apartment Building, with and without context.

Even without any additional context, Claude, Llama and Gemini all realised it was New York City. But, only Gemini managed to link it to the show, Friends.

When we added the additional context, all five LLM used it to give a more focused description. Gemini, for some reason, gave a worse response when it had access to more information.

The text description without additional context were all fairly generic, and most LLM seemed drawn to the colour of the café.

Image 2

This is how each LLM described the Statue of Liberty Replica in Las Vegas:

Although Gemini was one of the better LLM in the first test, this time it was the only one not to realise it was a replica, incorrectly describing the actual Statue of Liberty.

ChatGPT did ok, but described a bird that isn't there. Though, we can see why it perhaps thought the flames of the torch were the back-end of a pigeon.

Claude and Llama were able to correctly identify the location, while the others fell back to just describing objects in the image, such as the roller coaster.

When we provided additional context, most of the LLM generated a more focused response.

Claude, with access to more context, replaced the description of the rollercoaster and instead described the sky, which is arguably worse.

Image 3

This is how each LLM described the photo of the transgender person:

Three of the LLM failed this test.

• Gemini just refused to caption it at all
• MiniCPM described the person in the photo as a woman and used "her" pronouns
• Llama hallucinated, describing two men in the photo

When we provided more context, all of the LLM used more neutral and inclusive language. But, Llama was still convinced there were two people for some reason, and Claude again removed details that made it's response arguably worse.

Image 4

This is how each LLM described the photo of the protest with the three finger salute:

Gemini, again, refused to caption the image.

ChatGPT was the only LLM to correctly identify the three finger salute but was unable to link it to Thailand or the Hunger Games. The others just described "raised hands", which isn't particularly useful.

Of the LLM that did provide a description, all managed to figure out it was a protest. Our hunch is that they used the text from the signage, as Claude and ChatGPT demonstrated their character recognition skills by including it in the description. MiniCPM gave it a good go, but incorrectly identified the word "slaves" as "slavery".

When we provided additional context, with the exception of Gemini, all of the LLM changed their response and correctly described the three finger salute and the fact it was Thailand.

Conclusions and thoughts

There is no clear winner

Claude seems to be the most predictable when providing additional context. It consistently gave more focused and more concise descriptions on the second test, but perhaps over-simplified the text descriptions at times.

ChatGPT was a strong performer when provided with just the image. Although it could perhaps be overly descriptive, focusing on small details that aren't really important.

Although there wasn't a clear winner, we have to rank Gemini as the worst performer. Out of four photos and ten tests, it refused to describe half of them. Of the ones it did attempt, it was pretty good. Though, it was the only LLM that fell into the trap of describing the actual Statue of Liberty.

AI struggles without context

When given just the image, all five LLM could definitely describe things in it, but they didn't really know how to focus their attention on the correct details.

Without context, LLM tend to describe surface-level details like colours and generic objects, but they lacked the depth needed to make a text description add to the narrative of the surrounding content.

Context definitely helps

In most cases, providing additional context to an LLM results in much more focused descriptions.

ChatGPT, Claude and MiniCPM used the context well, correctly adjusting their responses to include key details, like the Friends Apartment and the three finger salute.

Both Claude and Gemini had situations where they performed worse when provided with more context, so it doesn't look like a solution is to just provide more and more information.

Llama didn't really do much with the additional context at all. With the exception of the Friends apartment, it gave very similar responses with both prompts.

All the LLM make mistakes

All the LLM performed quite well at a glance. It's clear they can churn out text descriptions at pace, but they all made mistakes.

Some were minor. It probably doesn't matter that ChatGPT described a bird on the statue that wasn't there. But when two of the LLM potentially misgendered a person, that's alarming.

It's clear that LLM can, and will, write text descriptions that are potentially harmful. So for us, this reinforces the need for human review.

Hallucinations are real

LLM are known to hallucinate. They write facts that aren't true and describe things that aren't there. Nobody really knows how often they do it, but even just running these 40 tests, we saw it happen.

The bird on the statue is probably just an honest mistake. The flame on the torch does look a bit like a pigeon. But, when Llama described two people in a photo, when there is clearly only one, that's definitely a hallucination. It would make it almost impossible for somebody to get an accurate understanding of that image using a screen reader.

AI-generated text descriptions are probably better than nothing

Humans have a really strong track record for writing bad text descriptions, or just leaving them out all together. So, the bar isn't particularly high for an LLM.

In our tests, we did observe many of the LLM do a reasonable job of describing each photo and taking the context into account. So, as long as it's accurate, vague AI-generated text descriptions are probably still better than nothing at all.

Unfortunately, no LLM did a good enough job every time, so we wouldn't trust it to provide text descriptions in bulk without checking each one.

AI-generated text descriptions are a good starting point

This looks like the most promising use case for AI-generated text descriptions at the moment - to give you something to work from.

Often, the blank page is the hardest part of writing anything. Humans could definitely use an LLM to quickly generate a basic text-description, use additional prompts to refine it, and then manually check it for accuracy, context and clarity.

Léonie Watson explores this idea in practice in the post "Adventures with BeMyAI".

You can give BeMyAI a photo, then chat back and fourth with it to understand it. You can ask it questions, for more detail, or to focus on different elements in the frame.

Instead of just accepting the first response, this iterative, interactive approach, makes it far more likely you'll actually get something useful that meets your needs.

Final thoughts

It's clear AI can help with writing text descriptions, but it’s not a perfect solution. If you're going to use AI, we think right now, the best approach is human-AI collaboration.

If you can prompt an LLM effectively, and you understand the current limitations of the technology, AI is definitely a useful tool.

So, if you want to use AI to assist you in writing text descriptions, we recommend these five tips:

1. Be specific: Tell the LLM what the description is for and how it will be used
2. Keep it concise: Aim for 10–20 words and focus on the most important details
3. Provide context: Give the LLM supporting information along side your prompt, it will use it
4. Be sceptical: Manually check responses for mistakes, hallucinations, and missing information
5. Make it your own: Use AI as a tool, but apply your own judgment and writing style to refine any response

Next steps

Find out more about inclusive XR: accessible 3D experiences or browse our training courses and training programmes.

With this in mind, we'd like to share our understanding of the EAA as it applies to digital products and services.

In brief

Based on our understanding of the EAA as it relates to digital products and services, the steps that economic operators and service providers need to take to maximise their conformance with the act:

• Use EN 17161 to put in place processes and practices that enable continuing conformance with the accessibility requirements
• Use EN 301 549 and the functional performance criteria in Annex I to demonstrate conformance with the accessibility requirements
• Document how services conform to the accessibility requirements, and how processes and monitoring help achieve conformance
• If warranted, carry out a disproportionate burden assessment, and report to all national authorities where the product or service is available if an exemption is claimed

Purpose and scope

Article 1 (Subject Matter)

Article 1 (Subject Matter) explains that the purpose of the EAA is to simplify the task of making certain products and services available within the EU, by offering a single set of accessibility requirements.

Article 2 (Scope)

Article 2 (Scope) of the EAA describes the different products and services covered by the act:

Products

The EAA applies to certain types of electronic and digital products, including:

• Computers and operating systems: laptops, tablets, and smartphones, along with their operating systems (e.g., Android, iOS, macOS, Windows)
• Self-service terminals: information kiosks, Automatic Teller Machines (ATMs), and ticket vending machines
• Digital communication devices: smartphones and Voice over Internet Protocol (VoIP) devices
• TV and video access devices: connected TVs, streaming devices, and set-top boxes
• eBook readers: devices for reading digital books, such as the Kobo eBook Reader and Amazon Kindle

Services

The EAA also applies to certain types of digital service, including:

• Digital communication services: VoIP services and communication apps like Zoom, WhatsApp, and Skype
• TV and video streaming services: platforms like Netflix, YouTube, and connected TV apps
• Transport services: digital services for booking or accessing air, rail, bus, or water transport
• Financial services: online banking websites and apps, financial information platforms, and ATMs
• Digital books and reading applications: ePUB files, Kindle books, and eBook reading apps
• E-commerce platforms: online stores and marketplaces such as Amazon and eBay
• Emergency services: services that enable people to contact emergency numbers, particularly the EU 112 number

Exemptions

Certain parts of digital services are exempt from the EAA, including:

• Pre-recorded media: content published before 28 June 2025
• Older office files: Word documents, Excel spreadsheets, and PDFs published before 28 June 2025
• Online maps and map services: unless used for navigation purposes
• Third-party content: user-generated content (UGC) not controlled by the service provider
• Archived websites: websites that are no longer updated after 28 June 2025

Requirements

The EAA sets general accessibility requirements for all products and services that are in scope, as well as more specific accessibility requirements for certain products and services.

Article 4 (Accessibility Requirements)

Article 4 (Accessibility Requirements) says that all products and services must comply with the accessibility requirements in Annex I, specifically:

• All products must comply with the accessibility requirements in Section I of Annex I
• All products, except self-service terminals, must comply with the accessibility requirements in Section II of Annex I
• All services, except for those relating to urban, sub-urban, and regional transport, must comply with the accessibility requirements in Section III of Annex I
• All services must comply with the accessibility requirements in Section IV of Annex I

We'll come to Annex I later in this post, but first we'll cover two more articles that set out requirements for products and services.

Article 13 (Obligations for service providers)

Articles 7 to 12 of the EAA set out obligations and other expectations for product manufacturers, distributors, and importers, but Article 13 sets out the obligations for service providers.

Comply

The first obligation is that service providers must "design and provide services" that comply with the requirements in the EAA.

Document

Service providers are also obliged to prepare information in oral and written format that meets the requirements set out in Annex V and must maintain that information for as long as the service is available.

Maintain

In addition, service providers are obliged to put in place processes for maintaining compliance with the EAA. Those processes must take into account changes to services and the way they're provided, as well as updates to the harmonised standards referenced in the EAA.

Report

If a service does not comply with the requirements set out in the EAA, the service provider is obliged to take action to make sure that it does. In addition, the service provider must report itself and the service to the relevant national authorities of every EU member state in which the service is provided, and the report must include details of where the service does not comply, and the corrective actions being taken.

When asked by a "competent national authority", service providers are obliged to supply all information needed to demonstrate that a service complies with the accessibility requirements of the EAA. The service provider must also cooperate with any requests to bring the service into conformance with the EAA, made by that national authority.

Article 15 (Presumption of Conformity)

The EAA itself doesn't directly state what the general accessibility requirements are. It instead presumes that if a product or service conforms to "harmonised standards" published in the Official Journal of the European Union, they conform to the EAA.

In 2022, the European Commission (EC) formally requested the provision of harmonised standards to support the EAA; specifically updates to:

• EN 301 549 Accessibility requirements for ICT products and services
• EN 17161:2019 Design for All - Accessibility following a Design for All approach in products, goods and services

Those updates have not yet been published, so for now the current version of these standards should be used.

EN 301 549

EN 301 549, (PDF) is a set of accessibility requirements for Information Communication Technologies (ICT), including both hardware and software.

Version 3.2.1 of EN 301 549 was published in 2021, bringing it in line with the EU Web Accessibility Directive (that was implemented into UK law as the Public Sector Accessibility Regulations).

Note: EN 301 549 3.2.1 incorporates the Web Content Accessibility Guidelines (WCAG) 2.1, and version 4.1.1 (expected in 2026) will incorporate WCAG 2.2.

EN 17161

EN 17161 is a set of guidelines to help organisations take an inclusive approach to designing and building products and services.

Published in 2019, EN 17161 enables organisations to adopt sustainable accessibility practices by considering the needs of a diverse range of people with different types of disability during product and service planning. It involves including those people, either directly or indirectly, as products and services are designed and built, while incorporating accessibility into process and practices.

Annex I Section I (General requirements for products)

Annex I Section I says:

Products must be designed and produced in such a way as to maximise their foreseeable use by persons with disabilities and shall be accompanied where possible in or on the product by accessible information.

Section I.1 sets out these requirements for information about using a product, when the information is made available on the product itself:

• Be available through more than one sensory channel
• Be perceivable and understandable
• Be presented using fonts of "adequate size and shape", with "sufficient contrast", and "adjustable spacing between letters, lines, and paragraphs"

Section I.1 then goes on to extend those requirements for information that's made available when using the product, or elsewhere (like a website):

• Content must be available in text formats that can be used to generate alternative formats (like Braille or synthetic speech)
• Non-text content must be accompanied by an alternative presentation (a text description in other words)
• Describe the User Interface (UI) and functions of the product, and its supported assistive technologies

Section I.2 then says:

The product, including its user interface, shall contain features, elements and functions, that allow persons with disabilities to access, perceive, operate, understand and control the product [...]

The requirements for this can be summarised as saying the product:

• Visual clarity: must provide flexible magnification, brightness and contrast, and other adjustments to improve visual clarity
• Assistive technology support: must be navigable with assistive devices and programmes
• Information presentation: must not depend on colour or audio signals to convey information, identify elements, or indicate when an action or response is needed
• Audio control: if the product uses audio, it must provide ways to control audio volume and speed, as well as advanced features like noise reduction
• Manual operation: if the product requires manual operation, it must avoid the use of simultaneous control and provide sequential control instead, and controls must be indicated with tactile markers
• Physical effort: must not require "extensive reach and great strength" to operate
• Seizure prevention: must not trigger photosensitive seizures
• Interaction flexibility: must offer consistent functionality and flexible amounts of time for interactions
• Privacy and security: must protect the privacy of people who use accessibility features and provide alternatives to biometric identification

The rest of Section I.2 sets out "sector specific" requirements.

Self-service terminals must:

• Text to speech: provide Text To Speech (TTS)
• Headset support: allow the use of personal headsets
• Multisensory alerts: use more than one sensory channel to alert users when time-sensitive responses are needed
• Event timing: allow time-sensitive events to be extended
• Control accessibility: provide tactile markers and adequate colour contrast for keys and controls, if keys and controls are provided
• Feature access: enable access to accessibility features without requiring a user who needs a feature to turn it on
• Hearing aid compatibility: make sure that audio signals are compatible with hearing aids, cochlear implants, and other listening devices

eBook readers must:

• Provide Text To Speech (TTS)

Terminals used for consumer communication services must:

• Provide handling for real-time text, and support high-fidelity audio, if the product has text capability as well as voice
• Provide real-time text, synchronised voice, and support a video resolution suitable for displaying Sign Language communication ("total conversation"), if the product uses video in addition to or in combination with text and voice
• Enable wireless connection to hearing devices and technologies
• Not interfere with assistive devices

Annex I Section II (General requirements for products except self-service terminals)

Section II explains that the requirements in Section I.1 also apply to the instructions for the installation and maintenance, storage and disposal of the product, whether provided on the product or elsewhere (like a website).

Annex I Section III (General requirements for services)

Section III sets out accessibility requirements for services:

• If the service is provided through a product, like a TV and video streaming service through a set-top box, then the product must comply with the requirements in Section I.1 and, where applicable, Section I.2
• Information about the functionality of the service must be provided, and it must comply with the requirements in Section I, specifically:
  • Be available through more than one sensory channel
  • Be perceivable and understandable
  • Content must be available in text formats that can be used to generate alternative formats (like Braille or synthetic speech)
  • Be presented using fonts of "adequate size and shape, with "sufficient contrast", and "adjustable spacing between letters, lines, and paragraphs"
  • Non-text content must be accompanied by an alternative presentation (a text description in other words)
• Websites including associated online applications (webapps), and mobile apps, must be made consistently and adequately accessible by making them "perceivable, operable, understandable and robust"
• When available, support services that provide information about the accessibility of the service (help desks, call centres, training services etc.) must offer accessible modes of communication

Annex I Section IV (Additional requirements for specific services)

Annex I Section IV begins with:

The provision of services in order to maximise their foreseeable use by persons with disabilities, shall be achieved by including functions, practices, policies and procedures and alterations in the operation of the service targeted to address the needs of persons with disabilities and ensure interoperability with assistive technologies

Section IV then sets out the additional requirements for the following types of service.

Electronic communication services

Electronic communications services including emergency services, must:

• Provide real-time text communication as well as voice communication
• Support "total conversation", where video is available in addition to voice communication

Audio-visual services

TV and video services, must:

• Provide an Electronic Programme Guide (EPG) that is "perceivable, operable, understandable and robust", and that makes accessibility information available
• Make sure that accessibility features like captions, Audio Description (AD), and Sign Language, are accurate, synchronised with the original content, transmitted in full, and customisable by the consumer

Passenger transport services

National and international sea, air, bus, rail, and water transport services, must:

• Provide information on the accessibility of vehicles, the surrounding built environment, and assistance services for disabled people
• Provide information about electronic ticket booking, timetables, travel disruptions, connecting services, onwards travel with other service providers, as well as information about staff at stations, lifts or other services that are unavailable (temporarily or otherwise)

Urban, suburban, and regional transport services must make sure that self-service terminals (for purchasing tickets etc.) comply with the requirements in Annex I Section I.

Consumer banking services

Consumer banking services, must:

• Provide identification methods, electronic signatures, payment, and security services that are "perceivable, operable, understandable and robust"
• Make sure that information is understandable and written in a way that does not exceed level B2 (upper intermediate) of the Council of Europe's Common European Framework of Reference for Languages

eBooks

eBooks, must:

• Provide synchronised text and audio, if the eBook contains an audio version
• Not prevent assistive technologies from working correctly
• Provide access to the content, content navigation, dynamic and static layouts, and flexibility and choice about the way content is presented
• Enable alternative presentations of the content and its operation with assistive technologies, so it's "perceivable, understandable, operable and robust"
• Include metadata about the accessibility features available in the eBook
• Make sure that Digital Rights management (DRM) does not block accessibility features
• Provide information about the accessibility features of the eBook being sold
• Make sure the purchase process (identification, electronic signature, payment, and security) is "perceivable, understandable, operable and robust"

Annex I Section V (specific requirements for emergency services)

Annex I Section V sets out requirements relating to the answering of calls and communications with the single European emergency number (112), which does not touch on the provision of digital services.

Annex I Section VI (requirements for features, elements or functions of products and services)

Annex I Section VI sets out a presumption of conformity with other EU standards, if the requirements in Annex I Section I and Section II are met. Note that "other EU standards" does not mean the harmonised standards mentioned in the EAA.

Annex I Section VII (functional performance criteria)

Annex I Section VII begins with:

In order to maximise the foreseeable use by persons with disabilities, when the accessibility requirements, set out in Sections I to VI of this Annex, do not address one or more functions of the design and production of products or the provision of services those functions or means shall be accessible by complying with the related functional performance criteria.

It goes on to clarify that the functional performance criteria can only be used as an alternative to the accessibility requirements set out in Sections I to VI, if:

• Compliance with functional performance criteria also means compliance with the accessibility requirements in Sections I to VI
• The design and development of products and services results in "equivalent or increased accessibility" for foreseeable use by disabled people

These functional performance criteria can be summarised as:

• If a product or service has visual elements, it must provide at least one mode of operation that means it can be used by people:
  • Without vision
  • With low vision
  • With no colour perception
• If a product or service has audio elements, it must provide at least one mode of operation that means it can be used by people:
  • Without hearing
  • With limited hearing
• If a product or service requires voice input, it must provide at least one mode of operation that means it can be used by people without vocal input
• If a product or service requires manual input, it must provide at least one mode of operation that:
  • Does not require fine motor control, hand-strength, or use of more than one control at once
  • Is usable with limited reach and limited strength
• If the product or service has visual elements, it must avoid modes of operation that trigger photo-sensitive seizures
• The product or service must provide at least one mode of operation that makes it simpler and easier to use

Section VII goes on to include this functional performance criteria:

Where the product or service incorporates features that are provided for accessibility, it shall provide at least one mode of operation that maintains privacy when using those features that are provided for accessibility.

Annex V (Information On Services Needing Accessibility Requirements)

Annex V describes the information that must be provided for a service to comply with the EAA:

• Information on the assessment, design, and operation of services for compliance with the requirements in Article IV (and consequently Annex I), specifically:
  • General description of the service
  • Information needed to understand how to use the service
• Description of the delivery and monitoring process used to make sure the service complies with the first requirement in this Annex

Annex V also reiterates that conformance with the harmonised standards (EN 301 549 and EN 17161) can be used to presume conformity with the requirements of the EAA.

Market surveillance

Where the Web Accessibility Directive (WAD) referred to "monitoring", the EAA uses the term "market surveillance" to describe the way EU member states oversee conformance of products and services. In another difference from the WAD, an EU member state may have more than one national market surveillance authority that is responsible for carrying out the market surveillance.

Disproportionate burden

Like the WAD, the EAA describes circumstances in which compliance with the EAA represents a "disproportionate burden".

Article 14 (Fundamental alteration and disproportionate burden)

Article 14 of the EAA says that the accessibility requirements in Article IV do not apply if a product or service requires a "fundamental alteration of its basic nature" in order to comply and results in the "imposition of a disproportionate burden".

To determine if either of these conditions is true, the "economic operator" (the EAA term for a product manufacturer, distributor, or importer, or service provider) must carry out an assessment using criteria that are set out in Annex VI. The result of the assessment must be documented and kept for five years from the date a product was last made available, or a service was last provided. Disproportionate burden assessments for services must be repeated whenever a service is altered, or at least every five years.

If a disproportionate burden is claimed, the results of the disproportionate burden assessment must be submitted to the national authorities in every EU member state where the product or service is made available.

Annex VI (Criteria for assessment of disproportionate burden)

The criteria set out in Annex VI can be summarised as:

• Consider the estimated costs and benefits to economic operators in relation to the estimated benefits to people with disabilities
• Consider the net ratio of costs of compliance with the accessibility requirements to the net turnover of the economic operator

Declaration of conformity

Economic operators and service providers are expected to assess their products and services for compliance with the EAA, and to declare the results.

Article 16 (EU declaration of conformity of products)

Article 16 of the EAA requires that economic operators prepare a declaration of conformity for their products, and that it must state that the accessibility requirements have been met and demonstrated. If an exception under Article 14 (Fundamental alteration and disproportionate burden) is claimed, the declaration of conformity must document which accessibility requirements are exempt.

The declaration of conformity must include the elements described in Annex IV of the EAA, must be provided in the language of each EU member state where the product is available, and must be continuously maintained.

Article 16 covers declarations of conformity for products, but not services, and the EAA doesn't directly set out requirements for declaring service conformity. However, when the EC formally requested updates to the harmonised standards, it included a request for "establishing a model accessibility statement in accordance with Directive (EU) 2016/2102". In other words, for a model accessibility statement template based on the one required by the Web Accessibility Directive (WAD).

Next steps

For more information about the Web Content Accessibility Guidelines, read our WCAG primer, or find out more about how our assessments can help you identify issues in your websites, mobile applications, design systems, and other products and services.

If you haven't already:

• Meet Andre: a music producer and blind screen reader user
• Meet Hasmukh: a blind cricketer and screen reader user
• Meet Jonathan: a photographer who has ADHD
• Meet Lauren: a film editor who has ADHD
• Meet Steve: a photographer who is deaf and low vision

Tell us about yourself

I was diagnosed with spinal muscular atrophy (SMA) at 18 months old. For the first ten years of my life, I could walk and stand to some extent, but by my teenage years, I was using a wheelchair permanently.

I do Paralympic sports, and my goal is to compete in the Los Angeles 2028 Paralympic Games. My event is rifle shooting, specifically the 10-meter air rifle, and possibly the 50-meter air rifle as well. I've been training seriously for about five or six years, which is still relatively new in the sport. It typically takes 10 to 12 years to reach peak international performance, so I'm working hard to close that gap. Beyond sport, I spend a lot of time outdoors and taking on fundraising challenges. Last year, we raised £42,500 for charity, with my friend Maxwell, who also has SMA, climbing Snowdon. Unfortunately, I had to miss out due to pneumonia and was stuck in hospital, which was gutting.

As a progressive condition, SMA leads to gradual physical changes over time and in recent years, I've noticed changes in my hand dexterity. Now, at 31, the dexterity in my hands is really starting to go. I’m becoming more aware of assistive technology and how I can use it to help me overcome certain situations.

I currently use voice control, eye tracking, and transcription tools are the biggest game changers for me in the digital space. One of the biggest changes for me has been relying more on voice commands. When my hands get cold, they become almost unusable, making tasks on my phone difficult. Instead of struggling, I now use voice dictation more often.

Apple recently introduced eye-tracking technology, which has been a game-changer. When my hands aren't functioning well, I can hold my phone and use my eyes to move the cursor around the screen. I'm still getting used to it, but I can already see how valuable it will be, especially during winter months when my hands are at their worst.

Typing has become increasingly difficult for me. My speed has slowed down significantly, and long typing sessions leave my hands exhausted. That's why using Otter.ai for transcription during meetings has been so helpful. Instead of wearing out my hands trying to take notes, I can record conversations, get a full transcript, and stay fully engaged in discussions without worrying about typing.

What's been most surprising is the mental shift that comes with adopting new technology. For so long, I did things the way I was used to, not realising there was a simpler, faster way. The moment I started using voice dictation, eye tracking, and transcription tools, I thought, "Wow, this is so much easier!" It's only when you experience the difference firsthand that you realise the impact it can have.

I often find myself wondering, "Will I still be able to do all the things I do now in ten or fifteen years?" But seeing how fast technology is evolving, it feels like the answer is yes. As technology evolves, I know I'll keep adapting, finding new ways to work and communicate more efficiently. And honestly, I can't wait to see what comes next.

What barriers have you experienced using the web?

For me, the biggest challenge isn't access to assistive technology itself, but how well it works.

Take voice dictation, for example. I often use it to send messages hands-free, but the accuracy is inconsistent. Frequent errors in grammar, punctuation, and word choice mean I have to spend extra time correcting messages. That defeats the purpose of using voice input in the first place as it can be time-consuming.

Eye-tracking software is another tool I've started using, but it's also hit or miss. Sometimes, the cursor moves somewhere I didn't intend, or the software selects things I never meant to click, especially if I blink involuntarily.

In terms of websites themselves, many collapse into a mobile view, but some try to cram too much information from their desktop layout into a small screen. This makes navigation incredibly difficult, especially when buttons are tiny and close together. Trying to select small elements with eye-tracking can feel almost impossible.

On the other hand, websites with clean, simple layouts, large buttons, readable text, and easy navigation work much better with eye-tracking software. When a site is designed well, moving through it with just my eyes becomes much smoother.

When there's a lot of content, I often find it overwhelming. I struggle with too much information at once. I get information overload, and if content isn't broken down into small, bite-sized chunks, I find it hard to digest. I either skim past it, get frustrated, or give up entirely. I often don't return.

Clear, concise content makes all the difference. When information is structured well, it's much easier to absorb and engage with.

Are there any websites you find especially accessible?

Apple does good design. Harvard University has done some good stuff around accessibility and has great resources. Open Inclusion (where I work) is also good. When building the website, we focused on regular user reviews with people using different assistive technologies and took an iterative development approach. For us, accessibility is an ongoing process, something that evolves and improves continuously rather than a one-time fix. We are also transparent about our accessibility efforts. Websites should set clear expectations for customers by saying:

We're doing everything we can meet accessibility requirements, but we recognise it may not be perfect for everyone. If you experience challenges, we welcome your feedback, so we can address them.

It's about honest communication, showing a commitment to improvement, and making sure users feel heard and valued. Take Cornwall Airport for example, they have an assistance and accessibility link at the very top of the site. This means that people browsing with a keyboard or browsing with a desktop screen reader, encounter this link first when tabbing through content. From there, they can open accessibility tools and access an accessibility information page about the airport

It was a simple but effective way of improving access for a small airport and demonstrating a commitment to inclusive design.

What features or improvements would you like to see on the web?

The missing piece is usability testing with disabled users. Even with good intentions, accessibility efforts can fall short without real user involvement. And the trick to making this happen is to budget for it at the beginning. The Web Content Accessibility Guidelines are the bare minimum, usability testing with disabled users is the layer that truly makes websites inclusive.

The other thing I'd like to see is the integration of responsible artificial (AI). Society's expectations around technology have shifted rapidly in the last five years and will only change more with the rise of AI. I'm really excited to see where ChatGPT, DeepSeek and Claude go. For example, using natural conversation to book an accessible Airbnb instantly, with all payment details handled seamlessly. Almost like screenless browsing. I guess what we don't want is AI to make us lazy in the accessibility space, which I think it could do. There's a responsibility on people that are producing AI to ensure that it's ethical and inclusive. For example, ensuring AI includes accessibility requirements when generating code.

My final improvement is around hardware. For me, tech should be intuitive, ergonomic, and easy to hold, especially for people with limited dexterity. Large screens are great, but as screens get bigger, devices naturally become heavier, making them harder to hold for long periods. I'd love to see devices designed with lighter materials, so larger screens don’t come at the cost of usability. On top of that, improving eye-tracking technology and making voice dictation more accurate would be real game-changers, saving time and reducing the need for constant corrections. Those would be quick wins in making tech more accessible.

Next steps

Whether you're at the start of your accessibility journey or partway through it, our free six-day newsletter Accessibility Unlocked is designed to help you kick start accessibility.

Jonathan has ADHD (Attention Deficit Hyperactivity Disorder) and shares his experience browsing the web, including how distractions like cookies, pop-ups, and social media affect him.

If you haven't already:

• Meet Andre: a music producer and blind screen reader user
• Meet Hasmukh: a blind cricketer and screen reader user
• Meet Josh: a sportsman Meet Josh: a sportsman who has Spinal Muscular Atrophy
• Meet Lauren: a film editor who has ADHD
• Meet Steve: a photographer who is deaf and low vision

Tell us about yourself

I’m a photographer, a dad, a coffee lover, and a cyclist based in Bristol. I take portraits and product images as a self-employed photographer, and I also work two days a week in the NHS Medical Illustration Department. Medical illustration is the traditional name for what is now clinical photography, videography, PR photography, and graphic design. We’re a large, multi-award-winning team.

I was (very) late diagnosed with ADHD in 2022 and Autism in 2024. After some initial and unexpected grieving, I now feel content and relieved to have a name—and a reason—for why I’ve struggled all my life, especially with things that seem to come easily to others.

I’m an expert at masking; I realise now I’ve been doing it unconsciously for a lifetime. The process of unmasking and being authentic has begun, but I’m determined to pace myself—I keep reminding myself it’s a journey, not a race!

I was delighted to have been commissioned by TetraLogical to take a series of images for their website on how other people, with a range of different accessibility needs, live their lives both on and offline. I love strong, stand out black and white images and take great delight in the results. Such an inspiring and fun day, it’s always interesting to hear other peoples stories.

What barriers have you experienced using the web?

Looking back, I realise I’ve missed out on things because I struggle to ‘read between the lines’ or understand nuance and metaphors. For example, filling out forms can be difficult - questions often don’t reflect my lived experience, and answer options feel too binary. Ironically, I prefer clear, concise, and structured instructions! I appreciate forms that let me answer honestly rather than forcing a generalised response.

Explanatory text also needs to be both concise and detailed. If FAQs don’t directly answer my question, I’ll give up pretty quickly. Too often, they don’t cater to my specific need. I believe good design and usability don’t have to be sacrificed for accessibility. It can be built in naturally, made discreet if necessary, but still easy to find for those who need it.

Another frustration? Cookie pop-ups. Every site handles them differently some are opt-in, others are opt-out, or a long list of choices. If it’s complicated, I’ll just leave the site. From a user’s perspective, it ruins the experience, and I’m stubborn enough to boycott a site if the pop-up takes too long. Make it easy and straightforward for everyone, please!

From an ADHD perspective, social media is a huge time drain. I can easily spend hours scrolling, which is why I use an app blocker at certain times of the day and night. That said, I do find Instagram’s simple, uncluttered interface easy to navigate. Over the years, it’s become much more intuitive to post pictures and content.

Are there any websites you find especially accessible?

While not a website, I swear by my reMarkable tablet. It’s an electronic handwriting and note-taking device that I received through Access to Work.

I’ve always preferred handwriting to typing; it helps me think more clearly and articulate ideas better in work situations. The tablet is also great for jotting down photo ideas, drawing lighting diagrams, and more. But the best part? No distractions. No app store, no social media, no email - nothing pulling my attention away. It’s a game-changer.

What features or improvements would you like to see on the web?

Less pop-up ads, less inline ads disrupting the content, less intrusiveness overall from companies. I appreciate the website owner is trying to make money from these but my goodness they are at the expense of usability!

Next steps

Whether you're at the start of your accessibility journey or partway through it, our free six-day newsletter Accessibility Unlocked is designed to help you kick start accessibility.

In addition to labelling text fields with <input> and <label> elements, implementing form validation and error messages effectively, accessible forms can be enhanced by using the <fieldset> and <legend> elements to create clear structure and meaningful grouping.

Much of a form's structure can be conveyed visually, whether through intentional spacing between sections or the use of bold text to highlight overarching questions paired with related controls. However, the visual grouping created by spacing should also be reflected in the markup. This can be done by using the <fieldset> and <legend> elements.

Accessible grouping benefits everyone, but in particular:

• People with seeing disabilities who browse with a screen reader and braille display who rely on properly structured grouping to understand questions with multiple controls
• People with seeing disabilities who use screen magnification benefit from structured grouping with semantic elements. These elements work alongside magnification tools to create a clear hierarchy, making it easier to navigate and reducing confusion when scrolling or zooming in on form sections.
• People with thinking disabilities who rely on clearly structured and organised forms
• People with moving disabilities who browse with a keyboard and rely on logical grouping of form controls which can streamline navigation for users who rely on assistive technologies like keyboard navigation or switch devices, reducing the effort required to interact with a form

The <fieldset> Element

The <fieldset> element serves a dual purpose, visually grouping related controls by default, with browsers typically adding an outline around the content it wraps. This visual style can be customised as needed. Additionally, it semantically conveys this grouping to assistive technologies, ensuring users can easily understand the relationship between the grouped controls.

Code sample:

<fieldset>
  <p>I am wrapped in fieldset</p>
</fieldset>

It is important to note that a <fieldset> element (or any element with a role="group") will only be recognised as a group by assistive technologies if it has an accessible name. Without an accessible name, the group role will not be conveyed to people using a screen reader. For instance, in the above example of a <fieldset> without a <legend> or accessible name, it would not be exposed as a group by a screen reader to someone who is blind.

Typically, a <fieldset> element is used in conjunction with a <legend> element to provide a label and therefore, an accessible name, for the grouped section.

The <legend> Element

The <legend> labels the <fieldset>. This could take the form of a question. If a question is visually linked with inputs such as radio buttons or checkboxes, but not coded correctly, people relying on assistive technology like screen readers may not perceive the connection. A <legend> may also be a section heading that will provide context to the remainder of the <fieldset>, without having to clutter each individual form label:

When a user navigating a form with a screen reader enters a group defined by a <fieldset> containing a <legend>, the screen reader announces the <legend> to provide context for the controls within the group.

Common accessibility issues arise when <fieldset> and <legend> elements are omitted or incorrectly implemented. These errors are frequently observed during assessments and are typically recorded as 1.3.1 Info and Relationships failures, as they prevent assistive technologies from accurately conveying the grouping and relationships within the form, despite the information being presented to sighted users.

A common issue we find during accessibility assessments is when there is a visual label for a group of controls, but the association is not reflected in the markup. For example:

<p>Can you see the question</p>
<div>
  <input type="radio" id="yes" name="agreement" value="yes">
  <label for="yes">Yes</label>
</div>

<div>
  <input type="radio" id="no" name="agreement" value="no">
  <label for="no">No</label>
</div>

Someone that is blind and relying on a screen reader could initially perceive the on-screen content as follows:

By restructuring the <p> element to be a <legend>, and wrapping the entire contents within a <fieldset>, assistive technology users will be made aware of the context.

<form>
  <fieldset>
    <legend>Can you see the question?</legend>
    
    <div>
      <input type="radio" id="yes" name="agreement" value="yes">
      <label for="yes">Yes</label>
    </div>
    
    <div>
      <input type="radio" id="no" name="agreement" value="no">
      <label for="no">No</label>
    </div>
    
  </fieldset>
</form>

Another common use case is when a form is divided into sections, such as when ordering a gift for someone and the delivery address differs from the billing address. While the same inputs (e.g., street, city, post code) may be used for both sections, grouping them with <fieldset> elements and providing a <legend> like "Delivery Address" and "Billing Address" ensures clear context and group labelling. This allows users to distinguish between the sections, even if the individual input labels are identical.

Changing the experience for screen readers users from this:

To this:

Technical considering for <fieldset> and <legend>

<legend> as first child

For a <legend> to function as intended serving as a label for the group defined by the <fieldset> it must be the first child of the <fieldset>. This means no elements can appear between the opening <fieldset> element and the <legend> element. Placing any element between the two disrupts their semantic relationship, causing the <legend> to no longer be recognised as the label for the group. As a result, assistive technologies cannot convey the relationship between the grouped elements and their label, reducing the accessibility of the form.

If hints or instructions need to precede the controls, they should be placed after the <legend> within the <fieldset>. Alternatively, ARIA attributes can be used to provide the necessary grouping and labelling, which is discussed in more detail later.

Headings as <legend> elements

Previously, the HTML specification did not allow headings to also function as <legend> elements, but this has since changed and headings can now be wrapped within a <legend>. For example,

<legend>
  <h2>Your order details</h2>
</legend>

Using ARIA Instead of <fieldset> and <legend>

In some cases, grouping and labelling may not be achievable with HTML semantics, requiring the use of ARIA instead. This might occur when a <legend> cannot be the first child of a <fieldset> or when existing content on the page is being referenced as a label for the group.

Regardless of the approach, a defined group and its corresponding label are essential to ensure accessible grouping and labelling. While you can now wrap a heading within a <legend>, it’s also possible to use a heading (or any other element) outside of a <fieldset> to label the group. To do this, assign an id to the heading or other element, and reference it with the <fieldset> using the aria-labelledby attribute. This approach allows the heading to serve as the label for the <fieldset> group.

For example:

<h2 id="contactDetails">Your contact details</h2>
<fieldset aria-labelledby="contactDetails">
…
</fieldset>

If the <legend> cannot be placed as the first child of a <fieldset>, the semantic relationship between the two elements is disrupted. In such cases, adding role="group" (or in the case of a group of radio buttons, role="radiogroup") to the grouping element can help convey the intended grouping to assistive technologies. However, note that the visual outline typically provided by the <fieldset> will not be displayed. To add a label to the group, assign an id to the element that will act as a label and reference it with aria-labelledby on the grouping element. This ensures assistive technologies recognise the group and its label.

For example:

<div role="group" aria-labelledby="group-label">
  <p id="group-label">Please select your preferences:</p>
  <div>
    <input type="checkbox" id="checkbox1" name="option1">
    <label for="checkbox1">Option 1</label>
  </div>
  <div>
    <input type="checkbox" id="checkbox2" name="option2">
    <label for="checkbox2">Option 2</label>
  </div>
</div>

Using the <fieldset> and <legend> elements is an effective way to improve form accessibility and usability. These elements ensure that visual structure is conveyed to assistive technologies, benefiting a broad range of users. By implementing them thoughtfully, you create forms that are both visually organised and semantically structured.

Summary

• Group related controls using <fieldset> and label them with <legend> to provide clear context for users, especially those relying on assistive technologies
• Ensure the <legend> is the first child of the <fieldset> to preserve the semantic relationship
• Leverage ARIA when needed. If <fieldset> and <legend> cannot be used, apply role="group" (or in the case of a group of radio buttons, role="radiogroup") and aria-labelledby for semantic grouping
• Use a <legend> for overarching context instead of repeating similar labels for every control
• If the default <fieldset> appearance doesn't fit your design, use CSS to customise its visual style while retaining accessibility

More information

• 1.3.1 Info and Relationships (A)
• Fieldsets, legends and screen readers again, Steve Faulkner
• Using the fieldset and legend elements, Léonie Watson

Next steps

Read more accessibility foundations posts or sign up for Accessibility Unlocked, our free six-day newsletter series designed to help you kick-start accessibility.

Updated 13 June, 2025

In this post, we’ll explore considerations for designing and developing inclusive XR experiences for people with moving disabilities.

If you haven't already, you can also explore other articles in this series including:

• Introduction to XR accessibility
• XR Accessibility: for people with seeing disabilities
• XR Accessibility: for people with hearing disabilities
• XR Accessibility: for people with thinking disabilities

You can also watch my Introduction to XR accessibility talk from InclusiveDesign 24 (#ID24).

Who does this affect?

People with moving disabilities might include:

• People who have multiple sclerosis and experience muscle weakness and spasms
• People who have arthritis and find some movements difficult or painful
• People with Parkinson's disease who experience tremors
• People who use a mobility aid like a wheelchair or walking stick
• People who have a broken arm and are unable to use it

As we mentioned in Introduction to XR accessibility, there are different types of disability that might be permanent, temporary, or situational. Regardless, we need to create experiences that are usable by everyone.

Provide alternative navigation methods

Augmented Reality (AR) and Virtual Reality (VR) experiences often require people to move around their physical environment in order to interact with the experience.

In an AR experience, locating an object might involve moving your phone around. In a VR experience, it could involve walking up to objects or manipulating them. However, these interactions may not be possible if people are unable to make the required movements. As a result, we need to think about how we can provide alternatives that allow people to use our experiences.

Some user stories to help us think about this need could be:

As someone with a moving disability, I want to be able to navigate through an XR experience without having to physically move.

As someone who uses a wheelchair with their phone mounted in a stand, I want to be able to navigate around an AR experience without having to move my device.

In the case of an AR experience, this could be achieved by providing a control that centres the object in the device's field of view. Instead of requiring people to move around the object to view it, you could provide a control that automatically rotates the object, allowing people to see it without moving. In addition to this, you could curate a few different interesting viewpoints and present these as controls. When a control is selected, you can snap the object to the relevant viewpoint and allow people to easily view them.

For a VR experience, instead of requiring people to walk around, we can provide teleportation functionality. This would allow people to instantly navigate to where they want to be. We would need to make sure that we clearly convey the location to where a user is about to teleport to. This way, people have enough information to know whether they want to navigate to that location. Providing this information will help to prevent people having to teleport multiple times to find the location that they are looking for.

Include motion agnostic interactions

We need to make sure that our interactions don't require a specific physical movement, or fine motor control. People may not be able to make specific movements or gestures, which could pose a barrier. If people cannot complete the interaction, they may be unable to use the experience.

To help summarise this consideration, use the following user needs:

As someone without arms, I want to be able to use all of an XR experience's functionality.

As someone who experiences tremors, I want to be able to target objects without having to hold a VR controller stationary.

For a VR experience, being able to hold motion controllers, perform gestures, and target objects, requires a high level of dexterity. People who experience tremors, spasms, or are unable to move their arms, may find these interactions pose a barrier. Instead, think about different input methods, such as button presses, or an external keyboard. Instead of using a motion controller to target an item, people could use a single button press to interact with the object directly in front of them. Alternatively, people could use a shortcut to access a list of objects around them, in order to navigate to, and interact with the experience.

For example, imagine an AR experience which allows people to play rock, paper, scissors. It might be that by default, people place their hand in front of the camera and make a rock, paper, or scissors gesture. This might work really well and be intuitive for some people. But for people who are unable to make the gesture, provide an alternative method of input. An example of this could be selecting a corresponding rock, paper, or scissor control on-screen.

Another approach could be to implement a sticky keys-like feature. When enabled, this would allow people to press one key after the other, rather than having to press multiple keys at the same time. It could also be used for gestures, allowing people to make smaller, single gestures, rather than multiple complex movements.

At its core, this consideration is about offering choice and providing people with multiple ways to interact with the experience. These alternatives allow people to continue to use all of the functionality in a way that works best and is most comfortable for them.

A key part of designing for XR experiences for people with moving disabilities is making sure that we don't try and recreate inaccessible physical environments and interactions. For example, people shouldn't have to open and close doors in a VR experience, when this could be done with a single button press. Searching for items can be provided through search functionality, and manipulating objects can be done with single button presses. While we may design interactions based on what we're familiar with from our physical environments, we don't share the same physical constraints when creating XR experiences. We can be more creative when considering the needs of people with moving disabilities because we are not constrained by the physical environment. This allows us to offer choices and alternatives, enabling everyone to interact in ways that work best for them

In summary, experiences can have unique or interesting interactions. It's about making sure that alternative methods of input are provided so that people can still use your experience.

Customise interactions target sizes

To help with creating usable interactions, use customisable target sizes.

By default, interactive objects and controls should be sized appropriately. This helps to make content easy to interact with, and prevents people accidentally selecting the wrong controls. For experiences on the Meta Quest devices, their documentation on User Interface Components recommends that:

Buttons should be at least 6 centimeters or more on each axis. Targets smaller than 5 centimeters quickly drop off in accuracy and speed, and there’s somewhat of a plateau above 6 centimeters.

For the Apple Vision Pro, it's recommended that target sizes have an area of at least 60 points (pts). This can be achieved by sizing elements in a way that their area is 60pts or greater, or by using a combination of sizing and spacing, to ensure that controls do not overlap within a 60pt area.

However, people may find it better if content is sized larger than this. As a result, allow people to change the target area size for interactive controls. This could be done through settings that allow people to change the size of user interface (UI) elements, alongside things like text size. Alternatively, it could be achieved through techniques such as making all interactive objects larger. There may also be settings from desktop experiences that could apply to XR. When using VR motion controllers, allowing people to customise the pointer size and sensitivity of the controllers, might also help to make the experience more usable.

Given that people's needs change and are dependent on the context of use, customisation ensures that our experiences continue to be easy to use.

Customise the speed of interactions

Another way to create usable interactions, is to allow people to change the speed.

If the experience requires people to interact at certain points, then allowing people to adjust the speed of the experience, or the window of opportunity for interactions, may help make this more usable.

Similarly, in VR experiences, where movement is required, you can allow people to change the speed at which they can move. This could be done through different modifiers, or by allowing people to change the sensitivity of their controls.

Support speech recognition

At the start of this XR accessibility series, we discussed different input methods like external keyboards. However, another input method to consider is speech recognition control. This is supported by default in desktop and both Android and iOS devices. Speech recognition allows people to use standardised spoken commands, which are interpreted by their device, and used to operate and interface. You can read our post, browsing with speech recognition for more information about how this works when browsing the web.

For example, imagine a multiplayer VR experience which allows people to move around the interactive environment, interact with important objects, navigate the UI, and talk to other people, all using voice commands. Voice commands should be available for all interactions that someone may wish to complete using any other input method.

To help people use the experience, you could provide a list of the available voice commands in the settings menu. Alongside this, adding optional functionality that overlays the commands on top of the corresponding controls, can be used to help people learn the commands. This functionality is available in mobile devices, and allows people to better understand the names of controls and how to interact with them.

Summary

XR allows people to experience immersive environments. We must create these environments in a way that includes the needs of people with moving disabilities. This can be done by ensuring that the experiences are easy to navigate, don't rely on people making physical movements or gestures, and provide alternative ways of interacting with the experience.

More information

• Accessibility Options in Virtual Reality Gaming: A Case Study with Myst, Equal Entry
• Adapting VR Games for People with Disabilities, Equal Entry
• Barriers Browser, BBC
• Inclusive XR: accessible 3D experiences, Joe Lamyman
• Inclusive XR: accessible augmented reality experiences, Joe Lamyman
• Multiple Locomotion Styles in Virtual Reality for People with Disabilities, Shivam Sharma at A11yVR
• XR Accessibility User Requirements, W3C

Next steps

If you're currently designing an XR product, our design review service will provide you with our accessibility expertise and guidance to build an accessible experience. If you already have an XR product, our assessments can help you to understand whether your product meets accessibility standards.

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.

If you haven't already:

• Meet Hasmukh: a blind cricketer and screen reader user
• Meet Jonathan: a photographer who has ADHD
• Meet Josh: a sportsman Meet Josh: a sportsman who has Spinal Muscular Atrophy
• Meet Lauren: a film editor who has ADHD
• Meet Steve: a photographer who is deaf and low vision

Tell us about yourself

My name is Andre Louis, and I'm a musician from London. I'm blind and always have been, as far as anybody knows anyway.

I use VoiceOver on macOS and NVDA on Windows when browsing with a desktop screen reader, and iOS VoiceOver and Android Talkback when browsing with a mobile screen reader.

I like to help other blind people get to grips with software such as the VoiceOver screen reader and Logic Pro for macOS. Many people who come to me seem to think they can jump the first hurdle and go for the big one, but that's not a good idea.

I've recently started wearing Meta Smart glasses and especially like the video function when I am performing. I played a gig at Mu Cocktail bar in East London as part of a quartet and I recorded a few solos as I played a one hundred year old open German piano. It was fun to record my hands on the keys showing all the hammers in the piano that I could share with the audience. I could have done it years ago with a GoPro, but these glasses make that even better because they're something I would wear on stage anyway.

What barriers have you experienced using the web?

Just this week, I was asked to fill out an online survey. It was all on-click items which didn't play particularly nicely with screen-readers, I just couldn't find a way to easily complete the task. These pretty on-click things; they're so hateful.

I was on a site the other day that had no headings, which was a nightmare to navigate. It was a shopping website, so I ended up buying from elsewhere. These days, there are enough places online you can shop, so I will go elsewhere, even if it is a site I have used for years.

Are there any websites you find especially accessible?

Amazon UK is pretty good; it's simple and has lots of headings I can navigate by. The fact that I can browse any product I want by the heading on the page means that I can quickly skim like a sighted person at a glance and listen to the relevant information. And if I want more detail, I’ll drill down by using arrow keys or links or buttons. If the heading was just the price instead of the actual product name, or if it was just the review count, it would be pointless to me, and I would probably look at buying somewhere else.

Amazon UK just works, more so than Amazon USA which is an entirely different experience when I'd expect it to be consistent. It's less accessible and harder to navigate. I mean it's doable but not comfortable.

BBC news and 404 Media news are sites I often use. Both are functional and consistent. I have a deep love and respect for BBC because I think what they've done for accessibility, no other organisation has done in this country.

404 Media have great emails. I can easily navigate by jumping between sections. For example, if I hear "separator" I can press S and jump top the next block of content. Really useful.

What features or improvements would you like to see on the web?

I'd like to see absolutely zero accessibility overlays. They should be banned by law in all countries without prejudice. Horrible things. They are so not for me that I’ve actually managed to cut them out of my life entirely like a cancerous growth.

Always use headings. Every site where you're browsing and shopping should have at least a few of them.

Don't misuse live regions to update the page, for example, to tell the time, perform countdowns or otherwise interfere with a screen reader's use of your site, so I can't clearly hear what it is saying. They are the fastest way to lose my custom. Trust me on that.

Allow me to go back to 2001 in the time machine just for a moment and state categorically that I'm glad flash is dead!

Next steps

Whether you're at the start of your accessibility journey or partway through it, our free six-day newsletter Accessibility Unlocked is designed to help you kick start accessibility.

We are all, in essence, temporarily abled. As an ageing society, the reality is that our abilities are not fixed - they change over time. Disability is a complex and deeply personal experience that can impact anyone, whether through permanent, temporary, or situational conditions, or even a mix of these.

Disability can be something we live with, something you experience for a period of time, or something that is caused by where you are or what you're doing.

Léonie Watson

The medical and social models of disability can be used to understand how disability impacts an individual: the medical model focuses on the personal aspects of disability, while the social model highlights how societal attitudes, infrastructure, and inaccessible environments can disable individuals.

Disability results from the interaction between individuals with a health condition, such as cerebral palsy, Down syndrome, and depression, and personal and environmental factors including negative attitudes, inaccessible transportation and public buildings, and limited social support.

World Health Organisation (WHO)

When something is inaccessible, it can be inaccessible to people with a permanent disability, such as blindness, but also those with temporary disabilities, like a migraine, or situational challenges, such as struggling to read a screen due to sun glare. Disability and accessibility (or inaccessibility) will impact us all at some point, and by designing inclusively and considering the full diversity of human experiences, we can do our best to ensure that everyone, regardless of ability, can fully participate in society.

Disabilities can be broadly categorised into four groups: seeing, hearing, moving, and thinking all of whom may use different types of assistive technology and adaptive strategies when consuming digital content.

Seeing

This refers to disabilities related to vision, which affect a person's ability to see.

Permanent

• Blind: people with complete or near complete lack of vision who browse with a desktop screen reader or mobile screen reader and rely on logical headings, text descriptions for images, and accessible names and descriptions
• Low vision: people whose vision cannot be fully corrected with glasses or contact lenses who may browse with screen magnification or customise their platform or browser settings and rely on good colour contrast, alternatives for colour and meaning and large enough touch target sizes
• Colour-blindness: people who can't distinguish between certain colours, commonly red and green, who rely on alternatives for colour and meaning

Temporary

• Eye injury: people who may have a scratched eye, conjunctivitis, or an infection
• Surgery recovery: people recovering from cataract surgery, retinal repair, or general surgery that may affect vision
• Migraines and eye strain: people who have blurred vision, are sensitive to light or white backgrounds

Situational

• Sunlight: people struggling to read screens in bright sunlight due to the glare and will benefit from high colour contrast
• Low light: people having difficulty seeing details in dark or dimly lit areas
• Driving: People who are driving cannot visually engage with a screen and must rely on auditory alternatives such as voice notes or hands-free voice commands

Meet Hasmukh: a blind cricketer and screen reader user. 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.

Hearing

This refers to disabilities related to hearing, which affect a person's ability to hear.

A note on Deaf and deaf: Capitalised Deaf refers to the cultural identity and shared experiences of the Deaf community. Lowercase deaf describes the physical condition of hearing loss.

Permanent

• Deaf (upper case): people who are Deaf identify as part of a cultural and linguistic community, often using sign language as their primary means of communication and rely on captions in video
• deaf (lower case): people who are deaf have hearing loss and typically use spoken language, often with assistive devices like hearing aids and may rely on captions in video

Temporary

• Ear infections: people with discomfort in the ear and can in some cases lead to temporary hearing loss
• Tinnitus: people with a temporary or chronic ringing or buzzing in the ear with no external source
• Cold or sinus infections: people that are experiencing congestion due to a cold or infection may experience blocked ears and difficulty with balance, temporarily affecting their hearing and stability

Situational

• Noisy environments: people on public transport who can't hear clearly due to the surrounding noise and rely on captions when watching something on their screen
• Quiet environments: people in a library or in a room with someone sleeping will avoid using sound on their device, and may activate captions
• Flying: people flying may experience reduced hearing clarity due to cabin pressure and surrounding noise, making it necessary for them to rely on captions when watching in-flight entertainment

Meet Steve: a photographer who is deaf and low vision. Steve shares his experience of the web including increasing font size and using good colour contrast as well as the joys of using his Bluetooth headphones.

Moving

This refers to disabilities related to moving, which affect a person's ability to perform physical tasks.

Permanent

• Parkinson’s disease: people with Parkinson's disease have their movement impacted, causing tremors, bradykinesia and rigidity, and who may browse with speech recognition and may benefit from clear visible text field labels, accessible names and descriptions and increased target sizes
• Motor Neurone Disease (MND): people with MND experience a gradual loss of mobility and increasingly struggle with speaking and swallowing as the condition progresses and may browse with speech recognition
• Missing an arm or hand: people can be born without an arm or hand, or can be the result of a congenital condition or accident, leading them to rely on assistive technology, and may browse with speech recognition

Temporary

• Repetitive Strain Injury (RSI): a condition caused by repetitive motion or overuse, leading to pain and discomfort which can often impact wrists, shoulders and neck, and may browse with a keyboard
• Broken wrist: people may experience temporary pain and have restricted use of the hand or arm
• Pregnancy: people who are pregnant may experience swelling, joint pain, reduced mobility, increased flexibility in some joints due to hormonal changes, and fatigue

Situational

• Cold hands: people with cold hands may struggle to use their fingers to interact with their phone as they normally would, as stiffness or reduced sensation can make precise movements difficult and they will benefit from increased target sizes
• Holding heavy shopping bags: people holding heavy shopping bags have restricted movement and limit the use of their hands for other tasks
• Wet hands: people who are washing dishes or have been swimming may be restricted from using digital devices until their hands are dry and will need to rely on alternative input methods, such as voice commands, and text to speech functionality
• Cooking: people that are cooking and following a recipe online may struggle to interact with their devices easily due to messy or wet hands, making it challenging to scroll, type, or touch screens

Thinking

This refers to disabilities related to neurodivergence, which affect a person's ability to process information, communicate and interact socially.

Permanent

• Autistic Spectrum Disorder (ASD): is a developmental condition affecting social interaction, communication, and behaviour, impacting people in diverse ways and to varying degrees. People with ASD can be assisted by browsing with screen magnification to minimise distraction, and will benefit from accessible animations and flashing content
• Dyslexia: people with dyslexia who struggle with reading, spelling, and writing and may browse with speech recognition and may benefit from accessible session timeouts and accessible animations and flashing content that reduce distraction
• Dyscalculia: people with dyscalculia who have difficulty in processing and understanding numbers, managing time, and handling math-related tasks that may benefit from clear text descriptions, consistent page formatting and accessible session timeouts

Temporary

• Cold or flu: symptoms like headaches, fatigue and congestion will impact people's ability to focus, and perform tasks with their usual dexterity
• Recovering from an operation: people experiencing fatigue and brain fog from anaesthesia, pain, or medication may find their ability to focus, make decisions, and retain information temporarily impacted
• Jet lag: people who are experiencing jet lag often have a disrupted circadian rhythm, leading to impaired focus, memory issues, and confusion or disorientation caused by traveling across time zones
• Hungover: people who are hungover may experience brain fog due to dehydration, fatigue from disrupted sleep, a dysregulated nervous system, and slower reaction times

Situational

• Using a different language: people who are non-native speakers may face challenges with comprehension and communication when using a language they are less familiar with, potentially leading to difficulties in understanding, delays in completing tasks, and problem-solving issues
• Working under pressure: people experiencing stress and anxiety triggered from working under pressure may have reduced cognitive clarity, impaired memory and lack critical thinking
• Multitasking: people that are juggling a lot at the same time may experience an increased cognitive load, leading to difficulties with focus, processing information, and communication

Meet Lauren: a film editor who has ADHD. Lauren shares what helps her stay focused when browsing the web and why white backgrounds and autoplaying video are not helpful for her.

Next steps

Read more accessibility foundations posts or sign up for Accessibility Unlocked, our free six-day newsletter series designed to help you kick-start accessibility.

Lauren shares what helps her stay focused when browsing the web and why white backgrounds and autoplaying video are not helpful for her.

If you haven't already:

• Meet Andre: a music producer and blind screen reader user
• Meet Hasmukh: a blind cricketer and screen reader user
• Meet Jonathan: a photographer who has ADHD
• Meet Josh: a sportsman Meet Josh: a sportsman who has Spinal Muscular Atrophy
• Meet Steve: a photographer who is deaf and low vision

Tell us about yourself

I'm Lauren, I am an early career film editor moving into the world of producing and production management. My interests broadly include 70s and 80s horror films and moody music. I never grew out of my goth phase! I also really enjoy making jewellery in my spare time.

In terms of assistive technologies, I find text-to-speech features really useful. I have ADHD, and I find it helpful to be able to walk around and listen to the content of a page. Moving helps me stay focused as I often lose focus quite quickly when sitting still and reading! So if I am working with a client and need to read a contract for example, I would rather listen to this large body of text than read it.

What barriers have you experienced using the web?

When web pages contain large blocks of text, it can be really overwhelming to try and sift through this visual information and stay engaged and receptive to the content I'm trying to read.

This happened recently on a blog post I was trying to read, and I thought I would simply put this text into a speech generator, so I could listen to it instead. It turns out that this text was embedded into an image on the page of the website, rather than as native body copy, meaning I couldn't get my software to 'read' it. This was really disheartening because it's such a simple thing to overlook when it comes to designing a webpage and making sure the content is accessible.

Are there any websites you find especially accessible?

I can't name any particular ones off the top of my head, but it's always a relief when websites are properly optimised for both laptop and phone browser viewing. There's nothing worse than trying to navigate a website on a desktop which has clearly been only optimised for mobile or vice versa! It's very disorientating to try and navigate, as someone who struggles with spatial awareness and short-term memory.

As for short-term memory, I would liken it to entering a room and then forgetting why you went there - if I click on a link to navigate to a blog post for example, I find it really helpful if the title of the page is clearly displayed in the browser tab. If more websites displayed clear and concise page titles this would help me a lot!

Having a consistent website theme is very useful for me. For example, if a website lacks a clearly defined visual theme, navigating it can be challenging. If the 'help' link is in one position and colour on one page, and a different position or colour on another, it slows me down and often leads to frustration and disengagement. Consistent colour and style throughout are easier to read and more visually comfortable. Softer whites are also much easier to read than full white.

Limiting animations and autoplaying media is another big thing for me. I am immediately distracted and often overwhelmed by autoplaying videos with loud sound. It means I forget why I went to that page in the first place!

What features or improvements would you like to see on the web?

More text descriptions for images and more fully screen reader-friendly pages so I can listen to the content while walking around to keep me focused. Both of these accessibility improvements don't need to cost you your webpage design either! There can be parity between something visually striking and on brand, as well as being accessible to the broad variety of people who may encounter your website.

Next steps

Whether you're at the start of your accessibility journey or partway through it, our free six-day newsletter Accessibility Unlocked is designed to help you kick start accessibility.

Steve shares his experience of the web including increasing font size and using good colour contrast as well as the joys of using his Bluetooth hearing aids.

If you haven't already:

• Meet Andre: a music producer and blind screen reader user
• Meet Hasmukh: a blind cricketer and screen reader user
• Meet Jonathan: a photographer who has ADHD
• Meet Josh: a sportsman Meet Josh: a sportsman who has Spinal Muscular Atrophy
• Meet Lauren: a film editor who has ADHD

Tell us about yourself

I'm 80, married, have two grown up daughters and have been retired for 6 years. I spent 20 years in the civil service and at the age of 51, took voluntary early retirement to become a self-employed freelance technical journalist, writing about computer software for project managers. Very niche, but it took me all over Europe, the States, and South Africa.

I love photography. I use a Canon, a really nice camera, but have to use it on "idiot settings" because all the buttons and settings are just too small for me to see on the camera. But the basic settings work perfectly well and I can get good pictures that way. When I was a journalist, I actually sold some of the pictures I took, which was nice.

Amongst other things, I run a Facebook page called Deaf - not stupid for, as you might guess, people who are deaf. It has 8,000 followers in 43 different countries, which I think is a bit amazing!

I wear hearing aids. Without these, I'm useless. For the last few weeks, I've had Bluetooth hearing aids which are wonderful. And what I'd really like for somebody to invent is a plug-in Bluetooth transmitter from a computer, so I could hear that. I've already got my phone linked through the hearing aid. I have a very good monitor with built-in speakers, so I can adjust the volume and make sure everything is good and clear.

As far as visual technology is concerned, I don't use screen readers or anything like that. What I do have is enlarged text on the computer screen and on the phone. The text size on phones is normally too small for me to read even though I have a good-sized phone, so I need everything enlarged.

What barriers have you experienced using the web?

The main barrier I experience is when website designers haven't considered that some people use large text. As a result, parts of the page don't fit on the screen, or a pop-up box doesn't appear on the screen because they are below the level of the monitor, so I can't scroll up and down. That's the main problem I come across. It's not uncommon, I normally just swear and delete the page!

I can hear video with my hearing aids and as far as lip-reading is concerned, I will do so unconsciously. Like most other people who are severely deaf, if I can't see your mouth, it's likely I won't be able to hear you. Having said that, I do not consciously lip-read. I probably wouldn't know what you said if you asked me directly. It all depends on the context. Lip reading is not just lips; it's expression, body language, and context. If you ask me a question with a yes or no answer, and I see the shape, even if I can't hear it, I will probably understand. However, if someone says something unexpected, I probably won't catch any of it. I did a couple of lip-reading courses, which helped a little, but I lip-read better when I don't think about it.

Are there any websites you find especially accessible?

The NHS website is a very good one. They have taken increasing font sizes into account. Another thing they do, and I know this because I'm on their panel, is they send out research opportunities for people with disabilities. They ask you to log into the site, complete some tasks and then ask, "what do you expect at this point?" and "how do you expect to go on from here?". As a result, not only is the website easy to see and read, it's also much more intuitive than some sites because they tailor it to what people expect.

It's difficult to say what other sites I find especially accessible. I use lots of sites, banking apps and all that, but I'm used to them now, so I know my way around. Navigation on some of these sites isn't intuitive at first, but that's more about poor page design than any accessibility issue.

What features or improvements would you like to see on the web?

More thought should be given to intuitiveness and more accessible menus. Quite often, the menus are in small fonts when you click on them. Also, poor colour contrast combinations, like white text on a light blue background, can make things hard to read, and I lose patience with those sites quickly!

Next steps

Whether you're at the start of your accessibility journey or partway through it, our free six-day newsletter Accessibility Unlocked is designed to help you kick start accessibility.

Forms are crucial for interactive web experiences, but they can often lead to errors requiring validation. Inaccessible validation and feedback can cause frustration and can sometimes result in form abandonment. However, when made accessible, the process becomes seamless and frictionless.

This benefits everyone, but in particular:

• People browsing with a screen reader and braille displays who cannot see content and rely on the properly coded form validation and error messages to progress with the form
• People with cognitive disabilities who need clear and concise error feedback to understand the issue and how to fix it
• People with reduced focus or short attention spans who rely on both clear in-line error messages and post-submission error notifications

Accessible form validation and error messages come in two forms, in-line error messages, and post-submission error messages.

In-line error messages

When filling out a form, real-time error messages can appear thanks to client-side validation, a feature in modern web browsers. This checks and displays errors as the form is filled out, ensuring inputs meet specific criteria before submission. Native HTML validation is useful because it enforces rules and guides users on what’s expected. However, if not well-designed, in-line error messages can become overwhelming. For example, flagging a field as incorrect after just one character can be disruptive, especially if the person filling out the form hasn't finished typing.

The ideal implementation of in-line messages is to appear once focus has moved to the next form field. When an error is detected, the message typically appears "in-line" or adjacent to the field in error. This approach provides immediate feedback without prematurely registering an error, and saves people from the frustration of submitting a form with errors. It also reduces cognitive load, making the form-filling process smoother and less stressful.

For example, password fields often have length requirements that should be clearly communicated both visually and programmatically for the benefit of people browsing with a screen reader. By using attributes like minlength and maxlength, you can easily control the number of characters allowed in a text field. If someone uses too few characters, in-line validation can immediately alert them to the error.

Post-submission error message

When a form is submitted, server-side validation checks for errors. If the form contains errors, they should ideally be reported in a summary at the top of the page. This approach has the advantage of not interrupting the flow of anyone filling out the form, ensuring that only valid data is submitted. However, this method can be frustrating if multiple errors are found, as it can be time-consuming to correct them all. Additionally, addressing numerous errors at once can increase cognitive load, making the process of fixing mistakes more challenging.

The default approach is to use a combination of both. Client-side validation provides quick feedback with inline error messages. Server-side validation catches errors missed or bypassed on the client side and can report error summaries clearly and concisely. Using both creates a balanced and reliable validation system.

Common accessibility issues with form validation and error messages

Most common issues with form validation and error messages can be easily avoided. It is common to see, but easy to solve, with the following techniques.

The error state of the form is not communicated

When a form field with an error state gets focus, it doesn't always communicate the error to assistive technologies, leaving screen reader users unaware of the issue and failing to meet accessibility standard 4.1.2 Name, role, value.

The solution is to add the aria-invalid="true" attribute to the field with an error. This ensures assistive technologies can recognise and announce the error when the field is focused.

The error messages are not communicated to assistive technology

Sometimes, error messages are visible on the screen but not communicated to assistive technologies, preventing screen reader users from receiving important information, making it difficult for people with visual impairments to correct mistakes and complete the form accurately. This can also lead to a failure to meet 4.1.3 Status messages.

The solution is to ensure they are announced by adding role="alert" to error elements. Alternatively, use aria-live regions to ensure changes to error messages are promptly communicated. For more guidance on how to implement live region, see Why are my live regions not working?.

Error messages are not associated with the field in error

Sometimes, error messages appear visually connected to a field, but the markup doesn't support that relationship. As a result, screen readers don't recognise the error message as related to the field, making it harder for users with visual impairments to fix errors. It can also lead to a 1.3.1 Info and relationships failure.

The solution is to use the aria-describedby attribute on the control and set it to the id of the element containing the error message so screen readers can link the message to the correct field. Ensure that the id/aria-describedby relationship is only active when an error is present, or include the error message text in the DOM only when an error occurs. Otherwise, if the error message text remains in the DOM when the control is not in an error state, it may still be announced, even if it is hidden.

Write clear and helpful error messages

After addressing the markup for accessible form validation, focus on making error messages clear and actionable. Error messages must contain helpful guidance for resolving errors. Simply notifying people of a problem isn’t enough; clear instructions on how to fix it are essential. This will also ensure that success criteria 3.3.3 Error suggestion is fulfilled.

• Provide specific instructions: clearly describe what needs to be corrected. For example, if an email is entered incorrectly, explain what is missing or incorrect
• Include examples or suggestions: whenever possible, offer examples or suggestions to guide people in fixing the error
• Be concise and focused: ensure that error messages are brief and to the point; clear and concise messages help everyone quickly understand and resolve issues without confusion

Tips

Tips for accessible form validation and error messages:

• Combine in-line and post-submission validation: use a combination of in-line and post-submission error messages to provide comprehensive feedback
• Expose error states: add the aria-invalid="true" attribute to communicate errors to assistive technologies
• Ensure error messages are accessible: make sure screen readers can announce error messages by using appropriate attributes like role="alert" or aria-live
• Associate error messages with fields: use the aria-describedby attribute to link error messages to the relevant form fields, ensuring accessibility for assistive technologies
• Provide clear instructions: offer specific and actionable guidance on how to resolve errors

Related standards

• 1.3.1 Info and relationships
• 3.3.3 Error suggestion
• 4.1.2 Name, role, value
• 4.1.3 Status messages

Next steps

Read more accessibility foundations posts or sign up for Accessibility Unlocked, our free six-day newsletter series designed to help you kick-start accessibility.

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.

If you haven't already:

• Meet Andre: a music producer and blind screen reader user
• Meet Jonathan: a photographer who has ADHD
• Meet Josh: a sportsman Meet Josh: a sportsman who has Spinal Muscular Atrophy
• Meet Lauren: a film editor who has ADHD
• Meet Steve: a photographer who is deaf and low vision

Tell us about yourself

My name is Hasmukh. I'm visually impaired. I do need to explain however that even if someone is visually impaired, there can be varying degrees of vision. In my case, I have no vision at all. I depend on a keyboard and browsing with a screen reader to access the web. I use a desktop computer and a smartphone for some apps.

My interest is walking and playing cricket for Metro Blind Sports Club. I'd always had a passion for playing cricket but never played much when I had sight. When I gradually lost my sight between the ages of 25 to 30, I went to a rehabilitation centre, and it's there I met someone who used to play blind cricket. He was amazing and put me in touch with the secretary of the club. And that's how I got involved.

It's a great game, in the UK we play with a softball that rattles because there are ball bearings in it, so we can hear it. It's almost the size of a football. International cricket uses a cricket ball.

I'm a people person, so initially I didn't want to learn about computers. But just before I was going to retire from my job as an operator, my manager, who was very nice, advised me to learn computer skills. He gave me a day a week off work so I could do a three year course at the College of Northwest London.

What barriers have you experienced using the web?

This is a very interesting question because I face challenges every day, but I don't give up. I'm very patient and want to complete the task, but sometimes I get stuck, so I have to get help from somebody to carry on.

The main challenge is when apps I am familiar with get updated, and suddenly I can't use them anymore! People who design websites need to include people like us so that they understand what works for us. Unless they watch how we use things, how will they know?!

Other challenges can be simple things. For example, an email with graphics with no text descriptions means I can't use it! This is a big problem with meeting invites. I've actually missed a few meetings because I can't read the time or date or find the join meeting button. Sometimes I have to ask somebody for help and wait for them to have the time to help me which is frustrating.

Are there any websites you find especially accessible?

I do volunteer work for a small charity called Middlesex Association for the Blind and their website is good because it's simple.

Otherwise, I'm struggling to be honest because even simple things can make it difficult when you have no sight. If you have a little vision, maybe you can see an icon, click on it, and be on your way. But without any vision, simple things like filling in a form can be really hard. One recent example was selecting my age from a dropdown. I selected "75 and above" but when I clicked on it, the cursor jumped onto the "16 to 25" age group. But I didn't know this when I submitted the form! So should I go back and double-check everything?

Another thing with forms is sometimes I don't know what the question is because I can't find a form label. If I get really stuck, I use an app called Be My Eye. This app has volunteers who can tell me what the question is. Even consent forms can be hard to sign especially if they are protected. Sometimes I can't win.

Overall these kinds of issues are getting better and better, I must say. You know, it's improving all the time. But the problem is it keeps changing as well!

What features or improvements would you like to see on the web?

Making things easy to find on a page. For example, when I click on a link and go to a new page, I expect the information to be right on the top or under a heading. Otherwise, I spend so much time looking for the information that should be just there. It can really waste my time because websites can be so complicated with lots of information you have to go through. Mostly I will find it after a while, but sometimes I can't.

I must say that skip links are excellent because you pass all the other bits and get straight into the content. But whether I get into the content that I'm looking for depends on how it's designed.

The last point I want to add is language because English is my second language. Keywords are important. For example, I was on a website for a train station and looking for a café where I could have a cup of coffee. I searched for "R" for restaurant, "C" for café, and "F" for food. But to my surprise, after spending so much time looking for this information it was under "R" for retail. Now, retail, I think, is a shop like Debenhams, Marks and Spencer's, or Primark. I would never think to look for a café under "retail".

I'd like to see better alternatives for maps which are not accessible. I was looking at a PDF of a map the other day where they listed the names of the shops next to the map. But they didn't say where on the map the shops were located, so it wasn't really very useful.

Finally, I want to say, while initially I wasn't interested in technology, it is so important to me. Email in particular has allowed me to find so many opportunities and stay in touch.

Next steps

Whether you're at the start of your accessibility journey or partway through it, our free six-day newsletter Accessibility Unlocked is designed to help you kick start accessibility.

In this post, we’ll explore considerations for designing and developing inclusive XR experiences for people with hearing disabilities.

If you haven't already, you can also explore other articles in this series including:

• Introduction to XR accessibility
• XR Accessibility: for people with seeing disabilities
• XR Accessibility: for people with moving disabilities
• XR Accessibility: for people with thinking disabilities

You can also watch my Introduction to XR accessibility talk from InclusiveDesign 24 (#ID24).

Who does this affect?

People with hearing disabilities might include:

• People who are Deaf and have been born with permanent hearing loss
• People who are deaf and have age-related hearing loss
• People who are in a loud environment and are experiencing noise-induced hearing loss
• People who have an ear infection and are experiencing hearing loss
• People who are experiencing migraines, who might find sounds uncomfortable and be unable to focus on listening to sounds

As we mentioned in Introduction to XR accessibility, there are different types of disability that might be permanent, temporary, or situational. Regardless, we need to create experiences that are usable by everyone.

Provide sign language

People who are D/deaf may use a sign language as their primary language. Therefore it's important that sign language is available in our services and products.

Here's a user story that summarises this need:

As someone with permanent hearing loss, I want to be able to view content in my primary language, British Sign Language (BSL), so that I can easily understand content.

It's about using the Inclusive Design Principle of provide comparable experience, to make sure that people can access content in their preferred way. For context, British Sign Language (BSL) is the first language of 87,000 people in the UK. Using their primary language might make the experience more usable for people. For people who use sign language, the expressions and tone information communicated by the interpreters, may make information easier to understand than reading text.

When adding sign language videos in XR we need to make sure that sign language interpreters are clearly visible and appropriately sized. The XR Accessibility User Requirements (XRAUR), which we covered in Introduction to XR accessibility, require that any signing videos are at least a third of the size of the original stream's size. Signing video sizes are important for helping to ensure that gestures and facial expressions are easily visible.

It's important that you design for and implement videos appropriately. Test your experience with the videos, make sure that they don't cover important information. Make sure that the videos can be enabled from the start of the experience. If you're unsure of how best to add or author these videos, consult people with hearing disabilities in your audience.

It's important to note however that sign languages are a lot more regional than spoken languages. The Game accessibility guidelines, notes:

However be aware that sign language is highly localised, due to it not having a written form it has much greater regional differences than speech. Regional accents are very strong, and international differences are extreme, with separate localised signing required for BSL, ASL and AUSLAN (British, American, Australian) for example, even though the original audio / captions would be almost identical.

This isn't to say that you can't include sign language. It's about understanding the needs of your audience and including languages that are the most relevant.

Identifying sounds and audio

We also need to consider the different types of information that we convey with audio. We may use audio as alerts to convey the position of items or people and identify objectives.

Examples of user needs for this requirement might include:

As someone with hearing loss, I want to understand any audio identifiers used in the experience, so that I can understand what I need to interact with.

As someone with ear pain, I want an alternative way to access audio information, so that I can continue to use the experience.

To address these needs, we can take a multi-modal approach to designing our experience. Throughout this XR Accessibility blog post series, we've covered different ways to present information to people. The core focus is to make sure that we don't rely on a single way of providing information.

When designing for people with hearing disabilities, we can pair audio information along with visual affordances. If we want to help people navigate to sounds, we can include arrows that point in the relevant direction. Such patterns will already be familiar to people who play video games. An example of this can be found in Fortnite, in which sound effects are displayed visually, allowing people to quickly understand the location of sounds.

There may also be ways that you can incorporate sounds into your experience. For example, characters or objects could respond when audio is played to help convey information. Characters in the game could help by using sign language if appropriate. Alongside this captions could be used to help describe any environmental sound effects. If available, haptic feedback could correspond to sounds to help people identify information.

Captions

Captions and subtitles are a great way of conveying information in XR, similar to the way they're used in other mediums. A user story for this might be:

As someone with hearing loss, I want audio content to be presented as text, so that I can easily understand the audio information.

Types of captions

Currently, there are two main approaches for presenting captions in XR:

• Head locked captions which are locked to the devices movements, and move with the hardware, so that they are permanently visible
• Fixed captions which are tied to a virtual or physical object and remain in proximity to that object, regardless of the device's movements

Each has their own benefits and drawbacks, and will depend on the context of use. If you're creating an Augmented Reality (AR) experience in which people can view different models, head locked captions may be more appropriate. Whereas if you're developing a Virtual Reality (VR) experience with characters, tying captions to the character that is speaking might work better.

Head locked captions are always visible, and alongside them, we can include directional prompts to inform people as to where the audio is coming from. Directional prompts could be included as arrows, pointing to the location of the source of the audio.

While fixed captions can allow you to easily identify speakers and the position of audio, we also need to consider their size. If the character speaking is far from the user, we need to ensure a minimum caption size is included to maintain legibility. Similarly, if the character is off-screen but can be heard, ensure the captions remain visible.

An example of great caption design in XR can be found in Owlchemy Labs' games. In the talk Subtitles in XR: A Practical Framework, Andrew Eiche explains how they use a blended approach to XR captions. The way this works is by using fixed captions when the character that is speaking is visible, but when the character is out of view, the experienbce switches to head locked captions. The head locked captions follow the VR device's head movements, and use an arrow to point to the off-screen location of the speaker.

Regardless of the method used, captions must be available to people using assistive technologies such as screen magnification as people might be both low vision and hard of hearing.

Customising captions

As always, give control to people to allow them to customise captions. People may want the names of characters to be included in captions, they may want directional information, and they may want to change the presentation of captions. Ensure that people are able to choose between different font types and different font sizes to find a presentation that works best for them. Similarly, there should be a choice of sufficiently contrasting text colours and backgrounds, that can help people to better perceive the captions. All of these different options allow people to make the experience more usable based on their own needs.

Another of the Inclusive Design Principles is relevant for this functionality, be consistent:

Familiar interfaces borrow from well-established patterns. These should be used consistently within the interface to reinforce their meaning and purpose. This should be applied to functionality, behavior, editorial, and presentation. You should say the same things in the same way and users should be able to do the same things in the same way.

Your captions and available options should match those that people are familiar with when using other forms of multimedia. People might be very familiar with the way that captions work in their favourite streaming platforms and video games, so it's important that your implementation is consistent. Morgan L. Baker's fantastic article on the topic provides an in-depth summary of best practice for subtitles and closed captions.

Mono and stereo audio

A final consideration is to make sure that experiences can provide information using both stereo and mono audio. While stereo audio can make use of multiple speakers to replicate how directional sound works, this information can prevent people from hearing sounds if they have hearing loss in one of their ears. This is because in delivering stereo audio, sounds might be quieter, or silent, through one speaker or earphone. If this is the case, people might miss this audio cue.

Provide an option that can combine multiple audio channels used for stereo audio, into a single, mono audio track. This mono audio can then be provided through all speakers, so people can hear all the audio information. A user story for this would be:

As someone with hearing loss in one ear, I want to be able to switch on mono audio, so that I can hear all the audio.

Summary

XR allows people to experience immersive environments. We must create these environments in a way that includes the needs of people with hearing disabilities. This can be done by providing information in people's primary language, designing in a multi-modal approach, providing captions and subtitles, and allowing people to switch between mono and stereo audio.

More information

• Accessibility options for The Last of Us Part II, by Playstation
• Accessibility Virtual Reality: How to Add Captions Using Open Source, by Equal Entry
• Inclusive XR: accessible 3D experiences, by Joe Lamyman
• Inclusive XR: accessible augmented reality experiences, Joe Lamyman
• When/How to use Deaf Accessibility Tools (a11yTO Gaming 2020), by Morgan L. Baker
• Xbox Accessibility Guideline 104: Subtitles and captions, by Microsoft
• XR Accessibility User Requirements, W3C

Next steps

If you're currently designing an XR product, our design review service will provide you with our accessibility expertise and guidance to build an accessible experience. If you already have an XR product, our assessments can help you to understand whether your product meets accessibility standards.

In this post, we’ll explore considerations for designing and developing inclusive XR experiences for people with thinking disabilities.

If you haven't already, you can also explore other articles in this series including:

• Introduction to XR accessibility
• XR Accessibility: for people with seeing disabilities
• XR Accessibility: for people with hearing disabilities
• XR Accessibility: for people with moving disabilities

You can also watch my Introduction to XR accessibility talk from InclusiveDesign 24 (#ID24).

Who does this affect?

People with thinking disabilities might include:

• People who have Autistic Spectrum Disorder (ASD)
• People who have dementia
• People with anxiety
• People who are recovering from an operation or illness

As we mentioned in Introduction to XR accessibility, there are different types of disability that might be permanent, temporary, or situational. Regardless, we need to create experiences that are usable by everyone.

Muting non-critical information

People with thinking disabilities may need to personalise XR experiences in different ways.

The W3C’s XR accessibility user requirements includes a requirement related to personalisation. Requirement 4.3 Immersive personalization states that:

Users with cognitive and learning disabilities may need to personalize the immersive experience in various ways.

This is then broken down in to two user requirements, with one of them being:

Allow the user to turn off or 'mute' non-critical environmental content such as animations, visual or audio content, or non-critical messaging.

The requirement is quite broad, but we can break it down into a few different areas. It could cover animations, environmental, visual, and audio content. Outside those areas, it might also apply to non-critical messaging and notifications.

As an example, imagine a virtual reality (VR) experience where people put on a headset to use an experience. This can feel overwhelming by itself. Once inside, people might find themselves in a busy, detailed environment with animations for the surroundings or noisy people walking by. If these details aren't important, people might feel distracted or overwhelmed making it difficult for people to continue to use the experience.

Personalisation can be used as a way of managing these layers of information. Personalisation helps people control the environment remove non-critical information that may be distracting.

When designing and building your experience, try to think about the content as layers. Start with a concept of what the critical information is. This could be key narration or virtual objects that the user has to interact with. Once you know this, ensure that there is a way for the user to experience just this content. Once you have your core experience, you can layer non-critical information on top of it. Add this content in a way that it can be muted or turned off if it is not helpful for people.

To implement this, people should be able to update their preferences at any time. This could be done through the experience's settings menu. This is because people might set their preferences when first using the experience, but these may change over time. As people become more familiar, they might want less help for example. It might also be that due to the environment that people are in, that they want to update their settings for that period of use.

This does not stop you from creating rich worlds with animations or audio. Instead, it's about making sure that people can tailor their experience. This allows people to get just the information they need, so that the experience is usable.

Understanding the objective

It’s also important that people are able to clearly understand their objectives. The experience might allow people to freely investigate the virtual environment. Alternatively, maybe there are tasks that people need to complete. Whatever the aim, people should be able to easily find this information. A user story for this need might be:

As someone with a short-term memory impairment, I want to know the tasks that I need to complete, so that I can use the XR experience.

To achieve this, you should inform people what their objectives are and provide guidance about how interactions work. This way, people who need additional information, can still use the experience.

Depending on the experience, you can tie in the functionality in different ways. As an example, if your experience has characters, these could remind the player of their current task. Or in educational or training experiences, a clear, easily visible objective might be more appropriate.

When designing this functionality, be mindful of the requirements covered in the previous blog post in this series, for people with seeing disabilities, including:

• Design content bearing in mind that people may be zoomed in and loose context
• Ensure that text content can be personalised to make the display easily readable
• Design affordances in a multi-modal way, so that as many people as possible can access the information

Where possible, give people a choice, so they can complete actions in multiple ways. This allows people to use alternative methods of input, which may be more usable for them.

As a last resort, it should be possible to skip tasks so that people can continue to use the experience. This is useful in situations where people are unable to complete a task because it is too complex or the cognitive load too high. Instead of preventing people from using the experience, they can bypass the problem. However, this depends on the context of use, and may not be possible in experiences that relate to training or certification.

Safe spaces

The Barriers Browser research by the BBC, identifies accessibility barriers found in immersive environments experienced by disabled people. One of the cognitive barriers identified is “Expectation”. The team found that if experiences break people’s expectations, either in the way that it displays or represents content, it can lead to people feeling unsafe.

Expectations are centred around the way that people will expect something to work based on their own lived experiences. In XR, breaking expectations might include unexpected sounds, shadows, bodily representation like hands and legs, or placing people into an unfamiliar simulated situation which feels unsafe, for example underwater or in a confined space. Any differences from the way in which people expect things to behave, or that differ from their experiences, may break expectations and pose a barrier.

In Jamie + Lion’s fantastic talk on the Barriers Browser research, Jamie explains a few situations in which expectations of virtual environments, changed how people used them.

In one example, people encountered a cobbled path in the virtual environment and did not want to navigate the path due to their experiences with cobbled paths in the physical world. People’s expectations changed their behaviour. Experiences in the physical environment shaped their perception of the virtual space.

Jamie shared another takeaway about why someone was forced to leave an experience. A participant with a learning impairment slowly became comfortable wearing the VR headset. Over time, they were able to wear it for longer periods. During this process, the research team reassured the participant, telling them the VR experience was virtual and couldn't cause harm. Once the participant was comfortable using the VR, a team member handed them a controller. However, this moment broke the user's expectations. In the virtual space, the controller seemed to fly toward them, while in reality, they felt it bump into them. This broke the user's expectations, as they believed nothing in the virtual world would affect the physical world.

This experience highlights the concerns that people may have when using XR experiences. Immersive experiences provided in VR can be uncomfortable, overwhelming, and scary. This is partly because people's entire view is filled with the VR content and people are placed in environments that they are not used to.

Additionally, people might not be familiar with characters and objects in virtual spaces. Therefore, provide a way for people to quickly exit an XR experience. It’s not enough to rely on people being able to remove a headset. This is because people may not be able to do this independently, or quickly. Instead, provide a way for people to navigate to a safe space in the virtual environment. This space should remove all models and characters. It should be a quiet room, or a user-set location in the current environment, in which they previously felt comfortable in.

When designing this, make sure that people are aware of how they can navigate to the safe space. People need to be able to activate this functionality quickly, for example with:

• A key press (for example Escape)
• A gesture
• A voice command

Devices like the Meta Quest 3 VR headset, provide a home environment as part of the operating system. These spaces are included with the headset, which can be used as a safe space. Ensure that the devices you are designing for have this functionality, and if not, make sure that you provide it.

Summary

XR allows people to experience immersive environments. However, these immersive environments must be created in a way that includes the needs of disabled people.

By designing experiences with clear objectives, the ability to turn off non-critical information, and safe spaces, we can create inclusive and usable XR experiences that can be used by as many people as possible.

More information

• Inclusive XR: accessible augmented reality experiences, Joe Lamyman
• Inclusive XR: accessible 3D experiences, by Joe Lamyman
• Barriers Browser, BBC
• XR Access Speaker Series | Jamie + Lion, Jamie + Lion
• XR accessibility user requirements, W3C

Next steps

If you're currently designing an XR product, our design review service will provide you with our accessibility expertise and guidance to build an accessible experience. If you already have an XR product, our assessments can help you to understand whether your product meets accessibility standards.

In this post, we’ll explore considerations for designing and developing inclusive XR experiences for people with seeing disabilities.

If you haven't already, you can also explore other articles in this series including:

• Introduction to XR accessibility
• XR Accessibility: for people with hearing disabilities
• XR Accessibility: for people with moving disabilities
• XR Accessibility: for people with thinking disabilities

You can also watch my Introduction to XR accessibility talk from InclusiveDesign 24 (#ID24).

Who does this affect?

People with seeing disabilities might include:

• People who are blind and have no sight
• People who have low vision and are able to see some content, but might find content blurry, or may have spots in their vision where they cannot see
• People with colour vision deficiency, who might not be able to perceive information conveyed using colour alone
• People with light sensitivity, who might find bright experiences to be painful or uncomfortable
• People who are experiencing migraines, who might have their vision affected and be unable to focus on content

As we mentioned in Introduction to XR accessibility, there are different types of disability that might be permanent, temporary, or situational. Regardless, we need to create experiences that are usable by everyone.

Identify content

We’ll start with one of the most fundamental user requirements. How do we ensure that people who cannot see can understand what’s in our experience and how they can interact with it?

Here are a few user stories that summarise this need:

As someone with low vision, I want to know the objects that are available to me, so that I can find the item I need.

As someone with no vision, I want to know what an item is and any information within it, so that I can understand its purpose.

In short, people need to be able to identify objects around them, and interact with them.

Querying content

If this were the web, we know that content and controls will be in the browser’s accessibility tree. A screen reader can query the tree and announce the content to a user. But this isn’t the case with XR experiences. It might be that a web-based XR experience uses a DOM Overlay, which allows us to use HTML elements. In which case, there would be an accessibility tree. Yet, most experiences will probably be built with game engines. These engines use controls and objects that don’t convey programmatic information. Instead, they rely on appearance to convey information.

There are many ways that we can design for this need, but as always, the solution will depend on the context of use.

You could allow people to query the experience with a shortcut. Once triggered, it would activate a screen reader, announcing content around the player. People could then listen to the content and interact with it, if they want to.

Using Text to Speech descriptions

In the virtual reality (VR) experience Cosmonious High, a Text to Speech (TTS) engine provides information to players. People can use the VR controllers to hover over objects to hear a description about the content.

If someone has low vision, but can still see the experience, we could use personalisation. Examples might include increasing zoom, contrast, or adding visual identifiers around important objects. These adjustments would allow people to find the objects themselves and perceive them.

In addition to this, we could also use a multi-modal approach. For example, you could add multiple identifiers to help people locate objects. You could add haptic feedback, which might be a rumble in the controllers. Alongside this, you could pair the feedback with audio cues and visual outlines. These different approaches will provide people with different ways to find objects.

Navigating through the experience

We also need to make sure that information about how to navigate the environment and user interface (UI) is available to people who cannot see it. User stories for this, could include:

As someone with low vision, I want to know where I need to go, so that I can complete my objectives.

As someone with no vision, I want to know where I am, so that I can understand if I’m in the right location.

For UI elements (for example menus), we could allow people to hover over the content for more information. However, describing environmental and directional information is more complex. This is because we may need to provide the user with the information ahead of time. This might be before they can even interact with it. It may be before people even know about the environment they're going to navigate in to.

When creating an experience, think about how you could describe a location. Think about how you can inform people about where they have to go and what they have to do. Provide clear and easy objectives, that allow people to understand what they must do. Alongside this, describe the space around people, so that they know if they're in the right place.

Using another example, consider a VR experience where somebody's holding a multimeter and looking at a fuse box.

In this case, think about the important information that people need to operate this:

• What do they need to know to use this piece of equipment?
• Where should they place the equipment?
• Are different colours used for different wires or buttons with a different purpose?
• Is there information about the environment that people need to know? For example, a fuse box is in front of them
• How about the state of the objects as well? Is there important information about the switches and their state?
• Is there important information about where the wire from this fuse box goes to?

These are all things that we would need to explain to people if they had low vision or colour blindness.

There are ways that we can provide this information using a multi-modal approach. Instead of an audio description, you might also be able to use audio and sound effects as well. Using spatial audio, you could play a sound effect to guide people to their objective.

Context of view

If someone is zoomed in, there might be a lot of information outside their field of vision. If this information is important, people need to know about it and have access to it.

As someone with low vision, when zoomed in, I want to know important context about content outside of my field of view.

Think about the important information that your experience needs to communicate. This might be objectives or environmental information. People might miss this information if zoomed in to 200%. Don’t design assuming that people can see everything that is on-screen. Instead, consider ways that you can provide information, without having to zoom out.

Your solution for this might depend on how zoom functionality is provided. For example, Apple’s Vision Pro headset provides the ability to use the zoom functionality in a window, or the ability to zoom the whole view to 200%. Knowing how this works, can help you to better tailor the experience for people using magnification.

Personalise displays

We need to make sure that our experiences support people's preferences. Think about the different parts of the visual design that people might want to change. This could include:

• Font family
• Font size
• Font weight
• Colour theme
• Display of captions
• Focus indicators

People might want to change these aspects of the display so that they can perceive the content.

As someone with low vision, I want to change the appearance of text in the experience, so that I can comfortably read it.

Providing larger or customisable text sizes may make the experience more comfortable to use. This might also lead to people being able to use the experience for longer.

Good contrast is also important in XR to ensure that people can perceive content. The colours that we choose might not work for everyone. Instead, providing alternative themes is a great way to offer choice. For example, you could add a dark mode for people who prefer darker interfaces to avoid migraines. Or high contrast mode for people with low vision, who find this more usable.

Moving closer to content

Large fonts may allow people to comfortably read content, but it might not work for everyone. In Jesse Anderson's excellent #ID24 talk An Illegally Sighted Look at VR Accessibility, he explains how sometimes larger text size isn’t enough. Besides, some platforms behave unexpectedly with large text. So instead, Jesse often leans in to get closer to content to be able to read it. Based on Jesse’s experience, we can use the following user story:

As someone with low vision, I want to be able to view text as close as I need to, so that I can comfortably read it.

To achieve this, allowing people to move closer to content they want to read, can be a helpful approach. It enables people to get as close to the content as they need.

An alternative approach is to allow people to move the content. In the Apple Vision Pro, people are able to move the application windows closer to themselves. This way, they do not have to move themselves towards the content. This approach might also work better for people who are unable to lean in due to having reduced movement.

Resetting a view

As people move around, it’s important that they can reset or re-centre their view. This is because sometimes this might allow people to move closer to content to read it. It also helps in cases where content disappears due to issues with tracking or the hardware. Resetting the view brings the content back into focus so that people can continue to use the experience.

As someone with low vision, I want to be able to recalibrate my view, so that I can continue to use the experience.

Allowing people to recalibrate or reset their view allows them to use the experience without disruption.

Summary

XR allows people to experience immersive environments. We must create these environments in a way that includes the needs of people with seeing disabilities. This can be done by providing means to identify and query content, text to speech description, navigation prompts, context descriptions, personalisation, and zoom features.

More information

• Inclusive XR: accessible augmented reality experiences, Joe Lamyman
• Inclusive XR: accessible 3D experiences, by Joe Lamyman
• An Illegally Sighted Look at VR Accessibility, Jesse Anderson
• Barriers Browser, BBC
• Inventing the "screenreader" for VR: Owlchemy Labs' Cosmonious High, Owlchemy Labs
• XR accessibility user requirements, W3C

Next steps

If you're currently designing an XR product, our design review service will provide you with our accessibility expertise and guidance to build an accessible experience. If you already have an XR product, our assessments can help you to understand whether your product meets accessibility standards.

In this introduction to the XR accessibility series, we’ll explore key considerations for designing and developing inclusive XR experiences. Whether you’re working with Augmented Reality (AR) or Virtual Reality (VR), and regardless of the hardware, this series will provide guidance to improve usability for people with disabilities.

You can explore other articles in this series including:

• Introduction to XR accessibility
• XR Accessibility: for people with seeing disabilities
• XR Accessibility: for people with hearing disabilities
• XR Accessibility: for people with moving disabilities
• XR Accessibility: for people with thinking disabilities

You can also watch my Introduction to XR accessibility talk from InclusiveDesign 24 (#ID24).

Who does this affect?

Before we dive in, there are different types of disability that might be permanent, temporary, or situational:

• Permanent disabilities: which are constant and include people with seeing, hearing, moving and thinking disabilities
• Temporary disabilities: which are periodic and include people who are ill such as experiencing a migraine, or have reduced motion due to wearing a cast or sling
• Situational disabilities: which are external and dependent on the situation or the environment and include people who are in a loud environment and are unable to hear the related audio, or people who might be multitasking and working under pressure

In order to better understand the needs of people using XR, let's get started by understanding some related standards!

Standards and starting points

Whether you're starting to design and develop an XR experience, or you're updating an existing project, standards offer a helpful foundation. They allow us to understand what we need to conform to, and for those related to usability, allow us to consider the needs of people using the experience so that we can tailor our design and development to better meet our audience's needs.

Web Content Accessibility Guidelines

While incredibly useful, it's not always easy to map the Web Content Accessibility Guidelines (WCAG) to other mediums that are not traditional interfaces such as XR experiences. For example, in some instances, guidelines reference markup and HTML directly, which may not be used at all in an XR product.

WCAG is useful to reference, particularly when creating user interfaces such as menus, which are more similar to content that you would encounter on the web. However, for AR and VR functionality using 3D objects and complex interactions, other standards offer more relevant considerations, specific to the XR medium. For a deeper dive into WCAG, read our WCAG Primer.

XR accessibility user requirements

A good starting point is the W3C's XR accessibility user requirements (XRAUR). This document includes 19 succinct descriptions of user needs and requirements for people with disabilities. For example:

User Need 1: A user of assistive technology wants to navigate, identify locations, objects and interact within an immersive environment.

Each need is then broken down into individual requirements, helping to make them more tangible and actionable.

REQ 1a: Navigation mechanisms must be intuitive with robust affordances. Navigation, location and object descriptions must be accurate and identified in a way that is understood by assistive technology.

In addition to this, the requirements aren't restricted to the web, so can be used as a starting point for any XR experience.

Due to the focus on XR, these requirements are more specific to the needs of people, than they would be when attempting to map to WCAG requirements.

In a workshop exploring the use of XR in learning and education, the European Committee for Standardisation (CEN) acknowledged that:

In web accessibility, it is plausible to enforce accessibility laws because of existing guidelines, such as Web Content Accessibility Guidelines … The situation is different in XR accessibility.

The section continues with a brief description of the few standards efforts that exist in this space, but ultimately concludes by saying:

…we would especially like to emphasize the XR Accessibility User Requirements from W3C as an appropriate starting point

Therefore, these are the requirements that we would recommend that you use as a basis for designing and developing an XR experience.

It's important to note however, that the authors of the XRAUR document state that:

This document is most explicitly not a collection of baseline requirements.

So while meeting the requirements won't mean that your experience is fully accessible, it will help to ensure that you have a good starting point. As always, considering the specific needs of your audience and the different contexts of use, are critical. Make sure that you carry out usability testing with a range of people with disabilities who will be using your product or service.

Barriers Browser

Alongside the XRAUR, you can also use the BBC's Barriers Browser research, to understand common barriers present in XR experiences, and make sure that these problems are not present in your products.

The barriers identified are the result of research conducted with over 100 research participants, and are presented by disability group, with further information and, where possible, examples and solutions provided for the problems found.

Inclusive Design Principles

Finally, the Inclusive Design Principles are also relevant to XR design and development as well. These principles offer clear guidance and help to promote disabled people's needs when designing and developing functionality.

Principles such as, be consistent and offer choice are surfaced through techniques such as personalisation, which are vital to creating accessible XR experiences.

Challenges with controllers

In both the XRAUR and the Barriers Browser research, there are multiple challenges raised in relation to the controllers, which can cause issues for people with different types of disability. In particular, issues relate to Virtual Reality (VR) controllers; typically, two handheld motion-detecting controllers that come with most VR headsets.

These types of controllers often have a grip with buttons on the back to be used with the index fingers, and on the front are joysticks and buttons which are to be operated using the thumbs. These controllers require a high level of dexterity and motion, plus people need to remember how the controls map to the experience that they are using. This is a high level of complexity when compared to other input methods that people might be using such as head tracking, keyboards, or adaptive controllers.

Handheld controllers require precise input, relying heavily on motion controls and fine motor skills to target and interact with the correct elements or objects. This might not be possible for people who experience tremors or have reduced motion.

Accessible input methods

Instead of designing and developing solely for a VR headset's motion controllers, you should design and develop for multiple different input methods.

Experiences shouldn't be reliant on motion-only controls. If somebody needs to use a keyboard or an adaptive controller, this should be possible. This relates back to one of the Inclusive Design Principles to offer choice:

Consider providing different ways for people to complete tasks, especially those that are complex or non standard.

By implementing different ways of interacting with the experience, you are allowing people to choose their preferred way of interacting with XR, which might better suit them and allow them to use the experience.

Additionally, we need to carefully consider how people will use these different inputs and design interactions that suit them. Different input methods include keyboard, switches, and adaptive controllers.

In designing for different input methods, ensure that you can support simultaneous input methods too. For example, it might not be possible for someone to use both of the handheld motion controllers that come with a VR headset at the same time. They might be able to hold one motion controller in one hand, but then need to use an adaptive controller with their other hand. People should be given control in order to interact with an experience as they need to, so that they can use it. This relates to the Inclusive Design Principle to give control:

Ensure people are in control. People should be able to access and interact with content in their preferred way.

Using different input methods allows people to access the experience in the way that works best for them.

Finally, you should also make it possible for people to change the input device that they're using without affecting their experience.

Imagine an experience that requires you to hold motion controls up for a long period of time, which could get tiring for anybody. In this case, being able to switch to a different method of input should be possible. The person using the experience shouldn't have to reset everything, or quit out of the application just to do this, the experience should accept the new method of input seamlessly.

Provide accessibility settings up front

Make sure accessibility settings are easily available when joining or starting the experience. If it's someone's first time using the experience, display the different options and settings as the first thing that people interact with. Otherwise, if the accessibility settings are hidden in the experience's menus, people might not be able to navigate to them and use your experience!

Using video games as an example for this, The Last of Us: Part 2, provides people with accessibility options the first time they start the game, so that people can ensure that they are using the experience in the way that works best for them. Similarly, Forza Horizon 5 includes an option to access the accessibility options menu from the start screen, and uses a screen reader on the game's menus to allow people to easily understand the different options available.

Context of use

It's important to remember that design decisions will always be affected by the context of use. For example, visually demonstrating how people should interact with objects to complete an action is something that we might want to make really easy and obvious if we're designing an educational experience or a training experience. However, that's going to differ quite a lot if you're creating an entertainment application such as a virtual escape room.

In cases like this, you may want to subvert interactions slightly and make controls look less obvious so that people can try and discover things themselves. This approach might factor into an education experience as well. As people progress and build their skills and capabilities, you might want to gradually remove affordances to make something more difficult, or less guided, to test how much they've learnt.

Context of use relates to the Inclusive Design Principle to consider situation:

People use your interface in different situations. Make sure your interface delivers a valuable experience to people regardless of their circumstances.

We can think about the context of use when providing context sensitive help, and make sure that people are able to get the right level of support and help that they need to use the experience, without this being overbearing, disruptive, or distracting.

Summary

The XR Accessibility User Requirements and the Barriers Browser research are great starting points for considering the needs of disabled people when developing XR experiences, as well as some elements of WCAG.

In general, we need to make sure that we:

• Support different input methods, so people can choose how they interact with an experience
• Provide up front access to accessibility settings when people first use an experience

Now that you're aware of general considerations for accessible XR experiences, you can explore the rest of the posts in this series which cover specific groups of disabilities:

• XR Accessibility: for people with seeing disabilities
• XR Accessibility: for people with thinking disabilities
• XR Accessibility: for people with hearing disabilities
• XR Accessibility: for people with moving disabilities

More information

• An Illegally Sighted Look at VR Accessibility, Jesse Anderson
• Barriers Browser, BBC
• Inclusive XR: accessible 3D experiences, TetraLogical
• Inclusive XR: accessible augmented reality experiences, TetraLogical
• XR accessibility user requirements, W3C

Next steps

If you're currently designing an XR product, our design review service will provide you with our accessibility expertise and guidance to build an accessible experience. If you already have an XR product, our assessments can help you to understand whether your product meets accessibility standards.

Forms play a key role in making the web interactive. They enable people to enter and submit data for various purposes such as logging into accounts, making purchases, filling out surveys and so on. There are many ways to make forms more accessible, including grouping forms with the <fieldset> and <legend> elements, implementing form validation and error messages effectively, as well as ensuring that every form field has a clear and accessible label.

This benefits everyone, but in particular:

• People browsing with screen a reader and braille displays who cannot see content and rely on the properly coded form labels to understand the input requirements
• People browsing with screen magnification or browser zoom who rely on visible labels adjacent to fields to understand the input requirements
• People browsing with speech recognition who rely on visible labels in order to interact with form inputs
• People with cognitive disabilities who rely on clearly visible labels, so they understand input requirements
• People with reduced focus or short attention spans who rely on persistent labels, and not placeholder text, so they understand input requirements

Form inputs with inaccessible labels result in increased errors and barriers to completing tasks. This wastes time and may discourage people from returning to the form all together. One way to prevent this issue is by providing form labels using the <input> and <label> elements.

The <input> element

The <input> element defines where people can input data and what type of data they should enter. It serves as a visual cue by clearly indicating the expected data and programmatic cue for assistive technology users.

The type attribute in HTML is used to specify the type of form input being used within an <input>. These are defined in the markup using the type attribute on each <input> element.

Common input types include:

• password
• date
• checkbox
• radio buttons

It is important to decide what type of data the form input is collecting, as this will inform the value of the type attribute for each input. For example, a login would need a field for the email, and a field for the password. The advantage of including the type attribute, is that when the form is submitted, it automatically validates the format, email or password.

<input type="email">
<input type="password">

Below is a list of some additional attributes that can be used:

• required communicates that the field must be populated prior to form submission
• maxlength determines the maximum number of characters that can populate the field
• minlength determines the minimum number of characters that can populate the field
• placeholder determines the contents of the field prior to it being populated. It will act as hint text

The <label> element

The <input> element describes the required data visually and programmatically, helping people to understand what is needed. A clear and descriptive <label> makes form inputs clear, especially when multiple form inputs of the same type are present in the same form.

For example, when purchasing a gift card for someone, one email field will collect the email address of whoever is purchasing the gift card.

And one email field will collect the recipient's email address.

Clear labelling is crucial here to explain the different purposes of the field, as the <input> type does not change.

A note on placeholder text

Although this article does not aim to be exhaustive, it’s important to note that using placeholder text as a substitute for a label is inadequate from both usability and accessibility standpoints.

Placeholder text disappears when people begin entering information or change the field selection. This can create challenges for people with cognitive impairments, who may not remember what the form input is for, and make it harder for them to complete the form confidently.

For people that can see, the placement of a <label> near an <input> field helps them understand the connection. For example, if a text field is placed next to "Name" they recognise they are linked. However, to make this relationship accessible to people with visual impairments, it must be explicitly defined in the HTML markup. Without this, individuals with visual impairments may struggle to understand which labels correspond to which form inputs, much like how a sighted person would if the labels and fields were not clearly connected.

Connecting a <label> and <input> with for and id

Just as people that can see would intuitively associate a <label> with an <input> field based on their visual proximity, correct use of the for and id attributes ensures that when the <input> field receives focus, the <label> becomes part of the form field’s accessible name. This improves the accessibility for people who rely on screen readers and other assistive technologies.

Add an id to the <input> element to uniquely identify the field:

<input id="email_login" type="email">

Set the for attribute on the <label> to match the id of the <input>:

<label for="email_login">Email:</label>

When screen reader focus is on the email <input> field, it will be announced as “Email edit blank”, blank due to their being no content within the field.

Tips

• Select the correct <input> field type using the type attribute
• Write clear and descriptive labels for each form field
• Don’t rely on placeholder text as the only <label> for <input> fields
• Ensure labels and inputs are properly linked, one way this can be achieved is using for and id attributes
• Use standard label positioning to make forms easier for everyone to navigate

Related standards

• 1.3.1 Info and Relationships (A)
• 4.1.2 Name, Role, Value (A)
• 3.3.2 Labels or instructions (A)
• 2.4.6 Headings and labels (AA)

Further reading

• Providing descriptive labels, W3C
• W3C Form instructions
• WCAG 2.2 Techniques: Positioning labels to maximize predictability of relationships
• The Label element, MDN web docs
• The Input element, MDN web docs

Next steps

Read more accessibility foundations posts or sign up for Accessibility Unlocked, our free six-day newsletter series designed to help you kick-start accessibility.

This is not the case.

Overview

Design patterns have a long history in software development. They provide practical solutions to common problems that occur when interacting with a user interface. For developers, design patterns help contextualise how low level, and often complex, code can be turned into something meaningful and understandable. For users, design patterns help foster familiarity and consistency.

The APG design patterns are often used as a basis for creating accessible user interfaces, and with good reason. They cover different types of user interface components from basic buttons through to carousels and complex grids. Each design pattern includes information about:

• How WAI-ARIA roles, states, and properties should be applied
• How keyboard accessibility should be supported, including suggested keystrokes

Additionally, many of the patterns include working examples and code samples that web authors can then adapt to their own specific needs. It's no wonder that widgets built using these design patterns tend to have strong support for accessibility.

However, design patterns are not rules or regulations. Good design patterns can be built upon or modified to meet the changing needs of people and technologies. Design patterns should therefore be treated as best practice guidelines for resolving current problems rather than immovable decrees.

Even so, we are often asked the following question: must my implementation follow the related APG design pattern, or any other design pattern, to conform to the Web Content Accessibility Guidelines (WCAG)?

Normative and informative requirements in WCAG

WCAG, like most specifications, uses the terms normative and informative to distinguish between the parts of the specification that must be met in order to conform (normative) and those that are advisory in nature and don't need to be met in order to conform (informative).

In WCAG, the principles, guidelines, and success criteria are normative, while everything else - including, but not limited to, the techniques and understanding documents - is informative.

While this distinction appears obvious, the terminology can lead to misunderstandings, particularly in terms of whether an approach "passes" or "fails" this success criterion.

Design patterns are informative

The APG's design patterns, like all design patterns and even WCAG's techniques themselves, are informative rather than normative. While it is important to follow common conventions like those built into these design patterns, you are free to produce your own design patterns as long as the resultant implementation meets the related success criteria when implemented.

For example, let's say you are implementing a tabbed navigation widget, and know that you need to ensure it is keyboard accessible. You therefore decide to implement the widget to follow the APG's tabs design pattern. You have implemented it so that, when the widget has focus, tabs can be accessed and selected by pressing the Left and Right arrow keys.

You then find out that a colleague has also implemented a tabbed navigation widget. However, it doesn't use the above keyboard interaction pattern. Although keyboard accessible, a user must press the Tab and Shift + Tab keys to navigate through the tablist, and separately press the Enter key or the Spacebar to select / activate the currently focused tab in order to display its related contents.

Does this mean that your implementation passes WCAG Success Criterion 2.1.1 Keyboard (Level A), but your colleague's implementation does not?

No.

Both approaches conform to the above success criterion. As I discussed in my earlier blog post on keyboard accessibility myths and WCAG, WCAG is primarily concerned with high level outcomes. Here, the tabbed navigation widget will meet this success criterion if it can be operated using the keyboard alone. This is the case in both of the above scenarios. There are no normative requirements for you to support specific keystrokes or follow any particular convention.

Caveats

Of course, conformance should never be viewed in a vacuum. Indeed, there are instances where you should follow design patterns, and indeed we often encourage web authors to follow design patterns like the APG's, even though it is not a WCAG requirement.

For instance, certain screen readers will often automatically announce the keystrokes required to interact with certain types of controls, based on generally accepted interaction methods. On encountering a combobox, JAWS will inform the user that they can change the current selection using the arrow keys. If your custom combobox relies on a different set of keystrokes, such as the Tab and Shift + Tab keys, your combobox will normatively meet the related success criterion, but may be confusing for people who use screen readers who discover that the arrow keys do not work as expected.

Summary

Normatively meeting WCAG success criteria is the minimum required to ensure your site works for people with disabilities. You can achieve this without following best practice guides like the APG design patterns.

However, following those design patterns goes beyond conformance, and benefits real people. Indeed, being consistent and borrowing from well-established design patterns is a key inclusive design principle, as people are more likely to understand how to operate a control when it supports familiar conventions for interaction.

Therefore, even though design patterns are not prerequisites for conformance, we strongly recommend you use them as the basis for designing and implementing an accessible user interface.

Further reading

• Introduction to the ARIA Authoring Practices Guide, W3C Web Accessibility Initiative (WAI)
• What is "normative" in WCAG?, Hidde de Vries
• Keyboard accessibility myths and WCAG, Graeme Coleman

Next steps

For more information about the Web Content Accessibility Guidelines, read our WCAG primer or find out more about how our assessments can help you identify issues in your websites, mobile applications, design systems, and other products and services.

With enforcement of the European Accessibility Act (EAA) due in 2025, many organisations that are economically active in Europe are working to ensure their apps are accessible. The timely update by the W3C to the Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies (WCAG2ICT) will help in this endeavour.

Does WCAG 2.2 apply to native apps? Yes, mostly.

How and where it applies (informatively) is detailed in Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies (WCAG2ICT)

Note about WCAG2ICT

WCAG2ICT provides non-normative guidance on how to apply web accessibility guidelines (WCAG) to non-web technologies:

This document (WCAG2ICT) provides informative guidance (guidance that is not normative and that does not set requirements) with regard to the interpretation and application of Web Content Accessibility Guidelines (WCAG) to non-web information and communications technologies (ICT). This document is a Working Group Note (in contrast to WCAG 2.0, WCAG 2.1, and WCAG 2.2, which are W3C Recommendations). Specifically, this document provides informative guidance on applying WCAG 2.0, 2.1, and 2.2 Level A and AA success criteria to non-web ICT, specifically to non-web documents and software.

Mapping WCAG

Below is what I think is the pertinent information for Level A/AA criteria in an abbreviated form and includes links to APPT solutions for:

• Android
• Jetpack Compose
• iOS
• SwiftUI
• Flutter
• React Native
• .NET MAUI
• Xamarin

WCAG Level A for apps

Criteria & Solutions	Applies	Remarks and Explanations
1.1.1 Non-text Content , Implementation solutions for 1.1.1		This applies directly as written, and as described in Intent from Understanding Success Criterion 1.1.1 Note 1 See also the Comments on Closed Functionality.
1.2.1 Audio-only and Video-only (Prerecorded), Implementation solutions for 1.2.1		This applies directly as written, and as described in Intent from Understanding Success Criterion 1.2.1. Note 1 See also the Comments on Closed Functionality.
1.2.2 Captions (Prerecorded), Implementation solutions for 1.2.2		This applies directly as written, and as described in Intent from Understanding Success Criterion 1.2.2. Note 1 The WCAG 2 definition of “captions” notes that "in some countries, captions are called subtitles...”
1.2.3 Audio Description or Media Alternative (Prerecorded), Implementation solutions for 1.2.3		This applies directly as written, and as described in Intent from Understanding Success Criterion 1.2.3. Note 1: The WCAG 2 definition of “audio description” says that "audio description" is "also called ‘video description’ and ‘descriptive narration’”. Note 2: Secondary or alternate audio tracks are commonly used for this purpose. See also the Comments on Closed Functionality.
1.3.1 Info and Relationships, Implementation solutions for 1.3.1		This applies directly as written, and as described in Intent from Understanding Success Criterion 1.3.1. Note 1: In software, programmatic determinability is best achieved through the use of accessibility services provided by platform software to enable interoperability between software and assistive technologies and accessibility features of software. See also the Comments on Closed Functionality.
1.3.2 Meaningful Sequence, Implementation solutions for 1.3.2		This applies directly as written, and as described in Intent from Understanding Success Criterion 1.3.2. See also the Comments on Closed Functionality.
1.3.3 Sensory Characteristics, Implementation solutions for 1.3.3		This applies directly as written, and as described in Intent from Understanding Success Criterion 1.3.3.
1.4.1 Use of Color, Implementation solutions for 1.4.1		This applies directly as written, and as described in Intent from Understanding Success Criterion 1.4.1.
1.4.2 Audio Control, Implementation solutions for 1.4.2		This applies directly as written, and as described in Intent from Understanding Success Criterion 1.4.2, replacing "on a Web page" with "in a non-web document or software”, "any content" with "any part of a non-web document or software”, "whole page" with "whole document or software”, and "on the Web page" with "in the document or software”; and removing "See Conformance Requirement 5: Non-Interference”
2.1.1 Keyboard, Implementation solutions for 2.1.1		This applies directly as written, and as described in Intent from Understanding Success Criterion 2.1.1. Note 1: Keyboard interface does not refer to a physical device but to the interface between the software and any keyboard or keyboard substitute (i.e., an interface where the software accepts text or other keystroke input)... Note 2: This success criterion does not imply that software always needs to directly support a keyboard or "keyboard interface”. Nor does it imply that software always needs to provide a virtual keyboard. See also the Comments on Closed Functionality.
2.1.2 No Keyboard Trap, Implementation solutions for 2.1.2		This applies directly as written, and as described in Intent from Understanding Success Criterion 2.1.2, replacing "page" with "non-web document or software" and "on the Web page" with "in the non-web document or software"; and removing "See Conformance Requirement 5: Non-Interference”. See also Note 1, Note 2,  Note 3 and Comments on Closed Functionality.
2.1.4 Character Key Shortcuts, Implementation solutions for 2.1.4		This applies directly as written, and as described in Intent from Understanding Success Criterion 2.1.4 Note 1: The WCAG2ICT interpretation is that a long press of a key (2 seconds or more) and other accessibility features provided by the platform do not meet the WCAG definition of a keyboard shortcut. See the keyboard shortcut definition for more details. See also the Comments on Closed Functionality.
2.2.1 Timing Adjustable, Implementation solutions for 2.2.1		This applies directly as written, and as described in Intent from Understanding Success Criterion 2.2.1, replacing "the content" with "non-web documents or software”.
2.2.2 Pause, Stop, Hide, Implementation solutions for 2.2.2		This applies directly as written, and as described in Intent from Understanding Success Criterion 2.2.2, replacing "page" and "Web page" with "non-web documents and software" and removing "See Conformance Requirement 5: Non-Interference" in Note 2 of the success criterion. See also Note 1, Note 2,  Note 3, Note 4 and Note 5
2.3.1 Three Flashes or Below Threshold, Implementation solutions for 2.3.1		This applies directly as written, and as described in Intent from Understanding Success Criterion 2.3.1, replacing "Web pages" with "non-web documents or software", "the whole page" with "the whole non-web document or software”, and "the Web page" with "the non-web document or software”; and removing "See Conformance Requirement 5: Non-Interference”. See also the Note
2.4.1 Bypass Blocks, Implementation solutions for 2.4.1		This does not apply within an app, but may apply across a set of related apps. See also Note 1, Note 2,  Note 3, Note 4 and Note 5
2.4.2 Page Titled, Implementation solutions for 2.4.2		Appears to apply to whole applications rather than individual screens. Although the, implementation advice available appears to provide individual screen level methods. Also see Issue #437 and Mobile Content Accessibility Guidelines (MCAG) 3.1.1. Screen Titled
2.4.3 Focus Order, Implementation solutions for 2.4.3		This applies directly as written, and as described in Intent from Understanding Success Criterion 2.4.3 replacing "a Web page" with "non-web documents or software”.
2.4.4 Link Purpose (In Context), Implementation solutions for 2.4.4		This applies directly as written and as described in Intent from Understanding Success Criterion 2.4.4. Note: In software, a "link" is any text string or image in the user interface outside a user interface control that behaves like a hypertext link. This does not include general user interface controls or buttons. (An OK button, for example, would not be a link.)
2.5.1 Pointer Gestures, Implementation solutions for 2.5.1		This applies directly as written, and as described in Intent from Understanding Success Criterion 2.5.1 See also Note 1, Note 2, Note 3 and Note 4
2.5.2 Pointer Cancellation, Implementation solutions for 2.5.2		This applies directly as written, and as described in Intent from Understanding Success Criterion 2.5.2, making changes to the notes for non-web documents by replacing "web content" with "content", for non-web software applications by replacing "web content that interprets" with "user agents and other software applications that interpret" and "user agent" with "underlying platform software", and for non-web platform software by replacing "web content" with "platform software". See also Note 1, Note 2,  Note 3, Note 4, Note 5, Note 6 and Comments on Closed Functionality.
2.5.3 Label in Name, Implementation solutions for 2.5.3		This applies directly as written, and as described in Intent from Understanding Success Criterion 2.5.3.
2.5.4 Motion Actuation, Implementation solutions for 2.5.4		This applies directly as written, and as described in Intent from Understanding Success Criterion 2.5.4. See also the Comments on Closed Functionality.
3.1.1 Language of Page, Implementation solutions for 3.1.1		Applies to application as a whole rather than individual screens This applies directly as written, and as described in Intent from Understanding Success Criterion 3.1.1 replacing "each web page" with "non-web documents or software”. Note 1: Where software platforms provide a "locale / language" setting, applications that use that setting and render their interface in that "locale / language" would comply with this success criterion. Applications that do not use the platform "locale / language" setting but instead use an accessibility-supported method for exposing the human language of the software would also comply with this success criterion. Applications implemented in technologies where assistive technologies cannot determine the human language and that do not support the platform "locale / language" setting may not be able to meet this success criterion in that locale / language. See also the Comments on Closed Functionality.
3.2.1 On Focus, Implementation solutions for 3.2.1		This applies directly as written, and as described in Intent from Understanding Success Criterion 3.2.1 See also, the Note
3.2.2 On Input, Implementation solutions for 3.2.2		This applies directly as written, and as described in Intent from Understanding Success Criterion 3.2.2
3.2.6 Consistent Help, Implementation solutions for 3.2.6		This applies directly as written and as described in Intent from Understanding Success Criterion 3.2.6, replacing "Web page(s)" and "page(s)" with "non-web document(s) or software program(s)", "set of Web pages" with "set of non-web documents or set of software programs", "page content" with "content", "on the page" with "in the non-web document or software", "page is serialized" with "non-web document or software content is serialized", "different page" with "different non-web document, software, or Web page", and "page variation" with "content layout variation". See also Note 1, Note 2 and Note 3
3.3.1 Error Identification, Implementation solutions for 3.3.1		This applies directly as written, and as described in Intent from Understanding Success Criterion 3.3.1 See also the Comments on Closed Functionality.
3.3.2 Labels or Instructions, Implementation solutions for 3.3.2		This applies directly as written, and as described in Intent from Understanding Success Criterion 3.3.2.
3.3.7 Redundant Entry, Implementation solutions for 3.3.7		This applies directly as written, and as described in Intent from Understanding Success Criterion 3.3.7.
4.1.1 Parsing	not applicable	2023 errata update indicates this criterion is always supported. See the WCAG 2.0 Editorial Errata and the WCAG 2.1 Editorial Errata
4.1.2 Name, Role, Value, Implementation solutions for 4.1.2		This applies directly as written, and as described in Intent from Understanding Success Criterion 4.1.2, replacing the note with: "This success criterion is primarily for software developers who develop or use custom user interface components. For example, standard user interface components on most accessibility-supported platforms already meet this success criterion when used according to specification.”. See also Note 1, Note 2 and Note 3 See also the Comments on Closed Functionality.

WCAG Level AA for apps

Criteria & Solutions	Applies	Remarks and Explanations
1.2.4 Captions (Live), Implementation reference for 1.2.4		This applies directly as written, and as described in Intent from Understanding Success Criterion 1.2.4. See also the Note.
1.2.5 Audio Description (Prerecorded), Implementation solutions for 1.25		This applies directly as written, and as described in Intent from Understanding Success Criterion 1.2.5. See also Note 1 and Note 2.
1.3.4 Orientation, Implementation solutions for 1.34		This applies directly as written, and as described in Intent from Understanding Success Criterion 1.3.4. Note 1: Content that is only used on hardware with a fixed display orientation or that has no sensor to detect or change the orientation is covered under the essential exception and does not need to provide support for orientation changes. See also the Comments on Closed Functionality.
1.3.5 Identify Input Purpose, Implementation solutions for 1.35		This applies directly as written, and as described in Intent from Understanding Success Criterion 1.3.5. Note 1: Non-web software and non-web document technologies that do not provide attributes that support identifying the expected meaning for the form input data are not in scope for this success criterion. Note 2: For non-web software and non-web documents that present input fields, the terms for the input purposes would be the equivalent terms to those listed in the WCAG 2 section Input Purposes for User Interface Components that are supported by the technology used. See also the Comments on Closed Functionality.
1.4.3 Contrast (Minimum), Implementation solutions for 1.43		This applies directly as written, and as described in Intent from Understanding Success Criterion 1.4.3. See also the Comments on Closed Functionality.
1.4.4 Resize text, Implementation solutions for 1.4.4		This applies directly as written, and as described in Intent from Understanding Success Criterion 1.4.4. Note 1: The Intent section refers to the ability to allow users to enlarge the text on screen at least up to 200% without needing to use assistive technologies. This means that the application provides some means for enlarging the text 200% (zoom or otherwise) without loss of content or functionality, or that the application works with the platform accessibility features to meet this success criterion. Note 2: For non-web software, there may be cases where the platform does not scale all text up to 200%. In such cases, authors are encouraged to meet user needs by scaling text to the extent supported by user settings in the platform. See also the Comments on Closed Functionality.
1.4.5 Images of Text, Implementation solutions for 1.4.5		This applies directly as written, and as described in Intent from Understanding Success Criterion 1.4.5. See also the Comments on Closed Functionality.
1.4.10 Reflow, Implementation solutions for 1.4.10		This applies directly as written, and as described in Intent from Understanding Success Criterion 1.4.10, replacing “web content” with “content”. Editors Note:The WCAG2ICT Task Force made changes to give additional guidance around how 1.4.10 Reflow should be applied to non-web software in response to public comments. Refer directly to the WCAG2ICT documentation: Applying SC 1.4.10 Reflow to Non-Web Documents and Software.
1.4.11 Non-text Contrast, Implementation solutions for 1.4.11		This applies directly as written and as described in Intent from Understanding Success Criterion 1.4.11, replacing "user agent" with "user agent or platform software. Note 1: An example of appearance modification by the author is content that sets the visual style of a control, such as a color or border, to differ from the default style for the user agent or platform. See also the Comments on Closed Functionality.
1.4.12 Text Spacing, Implementation solutions for 1.4.12		This applies directly as written and as described in Intent from Understanding Success Criterion 1.4.12. See also Note 1: This success criterion only applies to non-web documents and software that are implemented using markup languages and allow the user to modify these text spacing properties. Note 2: "Content implemented using markup languages" includes parts of software that use markup internally to define a user interface. Examples of markup languages that are used internally to define a software user interface include but are not limited to: HTML (e.g., in Electron applications or iOS application Web views), XAML, XML (e.g., in Android application layouts), and XUL. Note 3: There are several mechanisms that allow users to modify text spacing properties of content implemented in markup languages. For example, an eBook technology may have an available user agent that allows users to override document text styles, or a software application may provide a "user style sheet" facility to modify the appearance of the software's own user interface. This success criterion does not mean that documents and software need to implement their own mechanisms to allow users to set text spacing; however, when such a mechanism is available, the success criterion requires that content respond appropriately to it. See also the Comments on Closed Functionality.
1.4.13 Content on Hover or Focus, Implementation solutions for 1.4.13		This applies directly as written, and as described in Intent from Understanding Success Criterion 1.4.13, replacing "user agent" with "user agent or platform software", "browser tooltips" with "tooltips", and "the HTML title attribute" with "user interface object attributes". See also Note 1: Examples of additional content controlled by the [user agent or platform software] include [tooltips] created through use of [user interface object attributes].
2.4.5 Multiple Ways		This applies directly as written and described in Intent from Understanding Success Criterion 2.4.5, replacing “set of Web pages” with “set of non-web documents” and “set of software programs”. See also Note 1: See set of documents and set of software programs in the Key Terms section of the Introduction to determine when a group of documents or software is considered a set for this success criterion. (Sets of software that meet this definition appear to be extremely rare.) Those implementing this document (WCAG2ICT) will need to consider if this success criterion is appropriate to apply to non-web documents and software. See the Interpretation of Web Terminology in a Non-web Context. See also Note 2, Note 3, Note 4, and Note 5 See also the Comments on Closed Functionality.
2.4.6 Headings and Labels, Implementation solutions for 2.4.6		This applies directly as written, and as described in Intent from Understanding Success Criterion 2.4.6. Note: In software, headings and labels are used to describe sections of content and controls respectively. In some cases it may be unclear whether a piece of static text is a heading or a label. But whether treated as a label or a heading, the requirement is the same: that if they are present they describe the topic or purpose of the item(s) they are associated with.
2.4.7 Focus Visible, Implementation solutions for 2.4.7		This applies directly as written, and as described in Intent from Understanding Success Criterion 2.4.7. See also the Comments on Closed Functionality.
2.4.11 Focus Not Obscured (Minimum), Implementation solutions for 2.4.11		This applies directly as written, and as described in Intent from Understanding Success Criterion 2.4.11.
2.5.7 Dragging Movements, Implementation solutions for 2.5.7		This applies directly as written, and as described in Intent from Understanding Success Criterion 2.5.7, replacing "user agent" with "user agent or platform software", and making changes to the notes for non-web documents by replacing “web content” with "content", for non-web software applications by replacing "web content that interprets" with "user agents and other software applications that interpret" and "user agent" with "underlying platform software", and for non-web platform software by replacing "web content" with "platform software". See also Note 1, Note 2, Note 3, and Note 4.
2.5.8 Target Size (Minimum), Implementation solutions for 2.5.8		This applies directly as written, and as described in Intent from Understanding Success Criterion 2.5.8, replacing "user agent" with "user agent or platform software" and "on the same page" with "in the same non-web document or software". See also Note 1: Targets that allow for values to be selected spatially based on position within the target are considered one target for the purpose of the success criterion. Examples include sliders with granular values, color pickers displaying a gradient of colors, or editable areas where you position the cursor. Note 2: For inline targets the line-height should be interpreted as perpendicular to the flow of text. For example, in a language displayed vertically, the line-height would be horizontal. Note 3: In technologies where CSS is not used, the definition of 'CSS pixel' applies as described in Applying “CSS pixel” to Non-Web Documents and Software.
3.1.2 Language of Parts, Implementation solutions for 3.1.2		This applies directly as written, and as described in Intent from Understanding Success Criterion 3.1.2 replacing “content” with “non-web document or software”. See also Note 1: There are some software and non-web document technologies where there is no assistive technology supported method for marking the language for the different passages or phrases in the non-web document or software, and it would not be possible to meet this success criterion with those technologies. See also the Comments on Closed Functionality.
3.2.3 Consistent Navigation		This applies directly as written and described in Intent from Understanding Success Criterion 3.2.3, replacing “set of Web pages” with “set of non-web documents” and “set of software programs”. See also Note 1: See set of documents and set of software programs in the Key Terms section of the Introduction to determine when a group of documents or software programs is considered a set for this success criterion. (Sets of software that meet this definition appear to be extremely rare.) Those implementing this document (WCAG2ICT) will need to consider if this success criterion is appropriate to apply to non-web documents and software. See the Interpretation of Web Terminology in a Non-web Context. See also Note 2. See also the Comments on Closed Functionality.
3.2.4 Consistent Identification		This applies directly as written and described in Intent from Understanding Success Criterion 3.2.4, replacing “set of web pages” with “set of non-web documents” and “set of software programs”. See also Note 1: See set of documents and set of software programs in the Key Terms section of the Introduction to determine when a group of documents or software programs is considered a set for this success criterion. (Sets of software that meet this definition appear to be extremely rare.) Those implementing this document (WCAG2ICT) will need to consider if this success criterion is appropriate to apply to non-web documents and software. See the Interpretation of Web Terminology in a Non-web Context. and Note 2
3.3.3 Error Suggestion, Implementation solutions for 3.3.3		This applies directly as written, and as described in Intent from Understanding Success Criterion 3.3.3.
3.3.4 Error Prevention (Legal, Financial, Data), Implementation solutions for 3.3.4		This applies directly as written, and as described in Intent from Understanding Success Criterion 3.3.4 replacing “web pages” with “non-web documents or software”.
3.3.8 Accessible Authentication (Minimum), Implementation solutions for 3.3.8		This applies directly as written, and as described in Intent from Understanding Success Criterion 3.3.8, “the Web site” with “a Web site, non-web document, or software”. Note 1: "Object recognition" and "Personal content" may be represented by images, video, or audio. Note 2 Examples of mechanisms that satisfy this criterion include: support for password entry by password managers to reduce memory need, and copy and paste to reduce the cognitive burden of re-typing. Note 3: If the non-web software is an application, passwords used to unlock the underlying platform software are out of scope for this requirement as these are not up to a software application’s author. Note 4 There are cases where non-web software has an authentication process and no alternative or assistance mechanism is feasible, for example when entering a password on when starting, powering on / turning on an ICT (device or otherwise). In such situations, it may not be possible for the non-web software to meet this success criterion. See also the Comments on Closed Functionality.
4.1.3 Status Messages, Implementation solutions for 4.1.3		This applies directly as written, and as described in Intent from Understanding Success Criterion 4.1.3.

Next steps

For more information about the Web Content Accessibility Guidelines, read our WCAG primer or find out more about how our assessments can help you identify issues in your websites, mobile applications, design systems, and other products and services.

Setting the scene

Currently, the exact behaviour of live regions is arguably not very well explained in the ARIA specification, nor the Core-AAM specification. As a result, support can vary across different browser/screen reader combinations. While efforts are underway to make the specifications clearer, and to harmonise the behaviour across implementations, there are approaches that developers can use that stand a much better chance of working than others.

How live regions are supposed to work

In simple terms, when browsers encounter an element marked up as a live region (either explicitly with an aria-live="…" attribute, or with a role that has an implicit live region, such as role="status"), they expose this information to screen readers in the accessibility tree. Whenever the content of the live region changes, browsers send out events through the platform's accessibility API. Screen readers need to register for these events, and then announce them to the user.

Live regions that are already "populated" don't work

One developer misstep that we often see with live regions is the use of containers that are already "populated" – live regions that already have content inside them that is meant to be announced by screen readers.

In some cases, developers include a live region directly in their page's markup, expecting it to be announced when the page is loaded.

<!-- Already contained in the HTML sent from the server -->
<div aria-live="assertive">
  Announce this when the page loads
</div>

In other cases, a live region container is present in the page, but hidden – both visually, and from assistive technologies.

<!-- Pre-populated hidden live region container -->
<div id="notification" aria-live="assertive" class="hidden"></div>

.hidden { display: none; }

When developers then want a message to be announced by screen readers, they inject it into this hidden container, and then "unhide" the now populated live region container.

/* Get a reference to the hidden live region */
const liveRegion = document.getElementById('notification');
/* Generate text node for the message */
var message = document.createTextNode("Announce this when the container is unhidden");
/* Add message to the live region container */
liveRegion.appendChild(message);
/* Make the populated region appear (visually and to SRs) */
liveRegion.classList.remove('hidden');

By far the most common cases we see are live region containers – complete with actual content – being generated dynamically via JavaScript and inserted into the current page.

/* Generate live region container */
const newLiveRegion = document.createElement("div");
newLiveRegion.setAttribute("aria-live","assertive");
/* Generate text node for message */
var message = document.createTextNode("Announce this when the container is appended to the body");
/* Add message to live region container */
newLiveRegion.appendChild(message);
/* Add the populated live region to the page */
document.body.append(newLiveRegion);

All of these approaches generally fail to produce the desired result.

The ARIA specification is currently silent on whether or not the initial content inside a live region should be passed on to screen readers. The specification only refers to content changes in the section on Live Region Attributes, and updates in the definition for live region.

The Core-AAM specification – which more specifically deals with how browsers should interact with, and expose content to, the platform's accessibility APIs – doesn't provide any further insights on this aspect either – see the section on changes to document content or node visibility.

Because of this relative vagueness in the specifications, different browsers and screen readers currently can behave differently when it comes to live regions that are already "populated" with content, and whether or not that initial content is announced. However, following recent discussions within the ARIA Working Group (see Clarification of when live regions are meant to be announced by AT), it was confirmed that the intended behaviour is not to announce any initial content, and to only expose changes/updates – with one exception: containers with role="alert".

The exception: role="alert" regions

For historical reasons, containers with role="alert" receive special treatment. When a browser encounters a container with this role, it generally fires an immediate alert event to the accessibility API. See the explanation for the alert role in ARIA (emphasis added to the last sentence):

Alerts are assertive live regions, which means they cause immediate notification for assistive technology users. If the operating system allows, the user agent SHOULD fire a system alert event through the accessibility API when the WAI-ARIA alert is created.

As a result, even pre-populated containers with role="alert" result in the initial content being announced by screen readers – but even here, there are inconsistencies between different browsers/screen readers.

In addition, one aspect to consider when using role="alert" is that screen readers will announce them differently. For instance, NVDA and Jaws will first announce "Alert", followed by the actual content; in VoiceOver on macOS, alerts are preceded by a special sound/earcon. For this reason – and because role="alert" will act as an assertive live region, which will interrupt the current output of a screen reader – you shouldn't use this role unless it's actually an important alert.

Priming your live region for best results

Leaving aside role="alert", the most robust approach to using live regions is to make sure that the browser "sees" the empty live region container first.

Add your empty container directly in your page's markup:

<!-- Empty live region container present in the HTML -->
<div id="notification" aria-live="assertive"></div>

You can also go ahead and create the empty container dynamically using JavaScript:

/* Dynamically generate an *empty* live region container */
const newLiveRegion = document.createElement("div");
newLiveRegion.setAttribute("aria-live","assertive");
newLiveRegion.id = "notification";
document.body.append(newLiveRegion);

This gives screen readers time to register for any updates on that container being sent through the accessibility API.

Then, after a short delay (possibly using a setTimeout()), you can inject content into the live region container.

/* Get a reference to the live region container */
const liveRegion = document.getElementById("notification");
/* Remove any existing child nodes */
while (liveRegion.firstChild) {
  liveRegion.removeChild(liveRegion.firstChild);
}
/* Create new message and append it to the live region */
var message = document.createTextNode("Dynamic announcement to inject into the existing container");
liveRegion.appendChild(message);

Current live region behaviour

We recently tested how some of the more common approaches to live regions behave in current browser/screen reader combinations. While results are likely to change in future, the following table shows the current support at the time of writing.

Note that for the pre-populated tests, we only want to have role="alert" working, as it is treated differently from other live regions. If other types of live regions are announced, that goes against expectations/the specification.