This talk was delivered on 7 April 2026 as an introduction to digital accessibility.

Supporting Evidence for This Talk

This page brings together the sources, studies, and evidence that support the points raised in the session. It’s designed to help you explore the topics further, check the data, and follow up on anything you’d like to learn more about.

Outline

1. Who Disabled People Are
2. How Society Models Disability
3. Tools that Disabled People Use
4. Barriers Disabled Users Face
5. Barrier-Free Team Practices
6. Avoid Overlays

Who disabled people are

• Definition of disability under the Equality Act 2010 [GOV UK]

• 16 million people is derived from 1 in 4 people with Disability, according to Disability, accessibility and blue badge statistics, England, 2023 to 2024 [GOV UK]
• The spending power of Disabled people is referenced in Box 2 of ‘Disabled and vulnerable consumers: what support needs can firms meet?’ [University of Bristol]
• Most common disabilities identified in the Family Resources Survey [GOV UK]

How Society Models Disabled People

• Models of Disability [Scope UK]
• Assistive technologies [ATIA]

Tools that Disabled People Use

Mouth stick

From [TubusOne]

Switch button

Gliding Cursor and other switch settings [Apple Support]

iOS Accessibility features

• iOS Accessibility Features [Apple Support]

Barriers Disabled Users Face

Barrier 1

Carousel at smaller screens [CodePen]

Barrier 2

Increasing text size on iOS [Apple Support]

Barrier 3

Example of problematic banner animation with text [GAIN]

Barrier-Free Team Practices

Designers

• Mobile-first design [Figma]
• Understanding the importance of pausing, stopping, or hiding continuous animations [WCAG]

Developers

• Axe Core Linter [Deque]
• Accessibility API in Chrome Dev Tools [Google Chrome]
• Technique for ensuring keyboard support [WCAG]

Testers

• Understanding reading orders [WCAG]
• Understanding text resize to 200% [WCAG]
• Pa11y Dashboard [GitHub]

Avoid Overlays

• Factsheet & 1000+ signatures discouraging the use of Accessibility Overlays [Overlay Fact Sheet]

The post Digital Accessibility Series. Ep1: Understanding What Users Face appeared first on Tab-able.co.uk.

Formidable Forms is a widely used WordPress plugin promoted as accessible. Our testing shows otherwise.

Formidable Claims WCAG Accessible Forms

WCAG stands for the Web Content Accessibility Guidelines. Formidable Forms gives readers the impression of full WCAG and accessibility compliance, a high bar that few industries consistently meet.

We’re putting plugin accessibility claims to the test. Let’s get started by reviewing their opening claim:

“WCAG Accessible Forms + A11Y Compliance”

Alongside other statements of conformance such as:

“When it comes to ADA standards, WCAG and A11Y in website forms, Formidable is an industry leader.”

“…Get Formidable Forms and start building fully WCAG accessible WordPress forms”

Formidable’s claims may sound reassuring, but we found multiple WCAG failures. There is a clear gap between promise and experience for disabled users, including people who are blind, have low vision, cognitive disabilities, limited movement, or who use assistive technologies.

How is Formidable Measuring Accessibility?

Formidable measure accessibility using WAVE (an automated scan) and a short manual checklist. The WAVE result showed zero errors, which they appear to treat as sufficient. Their manual checks include mouse-free operation, TITLE attributes, and screen reader labelling.

While it is encouraging to see some effort being made, the use of the TITLE attribute is not required for digital accessibility. Other checks address only a limited number of WCAG Success Criteria, and the gap between the claims being made and actual conformance remains significant.

Automated tools only check the tip of the iceberg. Independent studies have found that tools like WAVE cover, at best, around 15 percent of WCAG success criteria.

Automated tools are useful for spotting surface-level issues, but they cannot verify whether a form is genuinely accessible. Unless Formidable Forms are clearly explaining how accessibility is being integrated into their product, with transparent steps and user-centred evidence, it is unlikely that inclusion is an ongoing part of their process.

What Formidable Forms Is Doing Well

Formidable Forms shows signs that accessibility has been considered at some point. Some features suggest that effort was made to support screen reader users, including:

• Use of standard HTML form controls
• Correct field labels
• Required and invalid states appropriately identified
• Some error messages correctly associated

Where Formidable Forms Falls Short

Despite some early signs of screen reader support, we found several WCAG failures in a basic form using default fields. Formidable says all versions are accessible, but these issues create real barriers for people with disabilities.

Not Entirely Screen Reader Friendly

Fails SC 1.3.1 – Info and Relationships

Screen readers in forms mode will not announce nearby text unless it is programmatically associated. This is especially important because users, including those who are blind or have low vision, often move between fields. If the message is not linked to the field, it will be missed.

Error messages related to groups of fields, such as “Checkboxes cannot be blank” are not programmatically associated.

No Autocomplete Support

Fails SC 1.3.5 – Input Purpose

When autocomplete is missing or misconfigured, people with memory, motor, or language impairments may struggle to complete forms at all. Without access to their stored personal data, even basic tasks like entering a name, email, and phone number can become barriers.

Personal fields such as first name, last name, email, and phone do not support autocompletion.

Poor Focus Visibility

Fails SC 1.4.1 – Use of Color

The submit button changes colour on focus, but not enough. Users navigating by keyboard, including those with low vision, cannot reliably see where they are.

• Default state: #4199FD (blue)
• Focused state: #3680D3 (slightly darker blue)
• Contrast Ratio: 1.38:1 (minimum is 3:1)

Low Contrast Text

Fails SC 1.4.3 – Contrast (Minimum)

People with low vision cannot easily read text when it is presented on bright colours. The minimum contrast threshold of text against background is 4.5:1 in this context.

Submit Button

• Default Contrast Ratio: white on blue (#4199fd) = 2.91:1
• Focused Contrast Ratio: darker blue (#3680d3) = 4.01:1

Error Text

For example, “There was a problem with your submission. Errors are marked below.”

• Red text (#F04438)
• On Pink (#FEE4E2)
• Contrast Ratio = 3.11:1

Low Contrast Field Borders

Fails SC 1.4.11 – Non-Text Contrast

This makes fields hard to perceive for people with low vision.

• Border colour: grey (#d0d5dd)
• Adjacent colour: white
• Contrast Ratio: 1.47:1 (minimum is 3:1)

Missing Labels and Instructions

Fails SC 3.3.2 – Labels or Instructions

People with cognitive, language, and learning disabilities cannot easily predict data formats.

Validation rules are not explained in labels or instructions. For example, phone numbers cannot contain brackets or extra spaces, but users are not told this.

Poor Error Suggestions

Fails SC 3.3.3 – Error Suggestion

People with cognitive or motor disabilities cannot easily correct their input without descriptive error messages.

When users enter the wrong format, they see vague messages like “Please match the requested format.”

Summary

Formidable Forms markets itself as accessible. But our testing shows it fails multiple WCAG criteria right out of the box.

So what does “accessible” really mean? From a user’s point of view, it can be hard to tell what’s genuine conformance and what’s marketing fluff. That’s exactly what we’re exploring next at Tab-able. We want to help you build forms that work for everyone.

Response from Formidable Forms

Formidable Forms have taken the feedback seriously and responded with the following points:

• [SC 1.3.1] This will be resolved internally
• [SC 1.3.5] Autocompletion is available as a field on the Pro version, but free versions can amend the shortcode in custom HTML
• [SC 1.4.1, SC 1.4.3, SC 1.4.11] Acknowledged
• [SC 3.3.2, SC 3.3.3] Not resolved at the moment.

Resources

• [Formidable] Opening Claims on WCAG
• [Formidable] Automated and Manual WCAG Methodology
• [Formidable] Response
• [Beau Vass] A false sense of accessibility: What automated testing tools are missing
• [Tab-able] Accessibility Solutions for Plugin Authors

The post Formidable Forms: Where Accessibility Claims Unravel appeared first on Tab-able.co.uk.

We often see links like “Read more”. But do they help you understand where it’s going?

Undescriptive links affect everyone, but they can disproportionately impact people with motion, cognitive, or visual difficulties. For these people, clicking a vague link only to land on the wrong page causes confusion and unnecessary back and forth navigation.

To fix this, you have a couple of options:

• Ideal: rework the link label so it makes sense on its own
• Alternative: add helpful context near to the link and programmatically associate it

Rework The Link Label (Ideal)

The best way to fix this is to change the link label so it makes sense on its own. For example, instead of “Read more”, say “Read more about Our Programme”. That way, people know what to expect before clicking.

This meets WCAG 2.2 Level AA & AAA:

• Level AA: SC 2.4.4 Link Purpose (In Context)
• Level AAA: SC 2.4.9 Link Purpose (Link Only)

Or Add Helpful Context

If there isn’t already context before the link, make sure to add it. A heading can help people with motion or cognitive difficulties understand what the link is for. That extra detail makes it easier to choose whether to click.

However, people with sight difficulties may still miss the full meaning if the link relies only on nearby text. To help, the link should be coded so that the context is clearly tied to it. This lets their assistive tools give the right information without extra steps.

This method meets WCAG 2.2 Level AA: SC 2.4.4 Link Purpose (In Context)

Use aria-describedby with an ID that points to nearby text. This links the description to the link so assistive tech can read both together. For example, a screen reader will read “Read more. Our Programme”.

Method 1: Add Description Manually

If you have access to the template code, you can add the following attributes directly, as shown below.

Simplified example:

<h2 id="context1"> Our Programme </h2>
...
<a href="#" aria-describedby="context1"> Read More </a>

Method 2: Use Our Script

If you can’t do this manually, for example if you’re a content editor, we’ve automated it for you via the script in our CodePen.

Either integrate the JavaScript from that CodePen into your content management system using a suitable tool, or ask your developers to do it for you. Then ensure:

• There is a descriptive heading before the link
• The link has the HTML class described

Caveat: some screen readers do not have descriptions enabled by default. This means aria-describedby relies on users having that feature turned on to receive the added context.

Now your “Read more” links should be clear, accessible and WCAG compliant. This reduces confusion and improves the experience for all users.

We hope this article has helped you meet at least WCAG Level AA. If you found it useful, please share it and leave a comment below. Your feedback helps us improve and reach more people.

Resources

• CodePen Demonstration
• Success Criterion 2.4.4 Link Purpose (In Context)
• Success Criterion 2.4.9 Link Purpose (Link Only)

The post A11y Tip: “Read More” Links appeared first on Tab-able.co.uk.

This final episode shows how the accessibility tree turns a video player into something blind users can press, play, and enjoy.

This is for curious readers, as well as Accessibility Experts, Developers, and Testers.

Blind people use screen readers to navigate and operate videos. When they do, the screen reader checks what type of control each part is. It looks for the type of button, its name, and whether it is open. It does not rely on how things look. It relies on what the website tells it.

This information comes from something called the Accessibility Tree. The webpage is the trunk, the video player is a main branch, the controls are smaller branches, and the content is the leaves. Trees make useful analogies because they can hide bugs and all sorts of critters.

This gets technical for good reason. If you’re up for a challenge, read on. We’re here to help, not to scare you off.

We’ll look at WCAG rules that help keep things in the tree organised and easy to recognise.

WCAG Robust: 2 Rules for Blind Video Access

The WCAG Principle Robust includes two rules that apply to making video players accessible for blind users:

• 4.1.2 Name, Role, Value
• 4.1.3 Status Messages

Let’s unpack these in plain language.

Does Your Video Have Controls?

If your video is decorative and has no controls, and you’ve met earlier episodes, congratulations because your video is accessible to blind users.

For everyone else we have to consider the following:

• Controls must clearly tell screen readers what they are, what they do, and whether they can be changed by the user
• Status messages must be written so that screen readers and other assistive technologies can understand and announce them clearly

Video players often include different types of controls. Some trigger actions, while others let users make choices.

All controls must be built so that screen reader users can understand and predict how they work. This means following official specifications.

The HTML and ARIA specifications explain how to build controls that work reliably across assistive technologies. These include desktop screen readers such as JAWS, NVDA, and Narrator, and mobile screen readers such as VoiceOver for iOS and MacOS, and TalkBack for Android. Users may be using any version of these tools.

Consistent specifications are essential. They help ensure that behaviour is predictable across all platforms.

Standard Buttons

Most video player controls are buttons that trigger actions like Play, Fast-forward, or Mute.

Blind screen reader users must be able to access both the name and role of each button. This helps them understand what the button is and what it does.

In video players, buttons are usually shown as icons. Their accessible name often comes from the icon’s text alternative or from an aria-label. That’s fine, as long as the name clearly describes what the button does. For example, use “Play” for a play button.

In addition to identifying the button, screen readers need to know its role to know what type of widget it is.

The simplest way to do this is by using the standard HTML <button> element, which automatically carries the role of “button”.

Simplified example of a native button:

<button ...>

If you cannot use <button>, you must add role="button" to your element to ensure it is recognised correctly. This is not the end of the world, but it won’t come with any bells and whistles. You’ll need to create that via scripts as well as ensuring it is keyboard accessible, including activating with the SPACE key.

Basic example of an ARIA button using a link with some keyboard support:

<a href="#" role="button">

Reveal Buttons

Some video players include other types of buttons, such as a control that reveals extra options. This is often shown as a settings cog icon.

This type of control is known as a menu button and displays a list of options when activated.

It must meet the same requirements as standard buttons, plus a few more:

• Users must know has a menu
• Users must know when the menu has been opened
• Users must know what kind of widget each option is
• Each option must have a clear name

Menu Popup

The aria-haspopup="menu" (or aria-haspopup="true") attribute is placed on the menu button itself. This tells screen reader users that activating the button will reveal a menu of options.

Simplified example of the popup type:

<button ...aria-haspopup="menu">

Menu Open

The aria-expanded attribute is placed on the menu button itself. Set it to true when the menu is open, and false when it is closed. This lets blind users know whether the options are currently visible.

Simplified example of the revealed state:

<button ...aria-expanded="true">

Simplified example of the hidden state:

<button ...aria-expanded="false">

Option Type

The type we set will depend on what the option does.

• menuitem performs an action when selected
• menuitemcheckbox selects or deselects an option; multiple checkboxes in the group can be selected
• menuitemradio selects one option from a group; only one can be active at a time

In the case of checkboxes and radio options, the checked states must be conveyed by the tree via states via aria-checked.

Options must be grouped inside an element with role="menu".

Here’s a simplified example of quality options with SD selected:

<div role="menu">
   <div ...role="menuitemradio" aria-checked="true"> Standard Definition (SD) </div>
   <div ...role="menuitemradio" aria-checked="false"> High Definition (HD) </div>
</div>

Option Name

The name of each option should be clear and come directly from its value. If you use plain text and the correct role, the accessibility name is automatically set. For example, in the previous simplified quality options, the names are “Standard Definition (SD)” and “High Definition (HD)”.

All together we have something that looks like this:

<button aria-label="Settings" aria-haspopup="menu" aria-expanded="true">...</button>

<div role="menu" style="display:block">
  <div role="menuitemradio" aria-checked="true"...> SD </div>
  <div role="menuitemradio" aria-checked="false"...> HD </div>
</div>

Technical note: We left out aria-controls on the menu button and aria-labelledby on the menu to keep things simple. These attributes are not required to meet WCAG, but they can help screen reader users. To learn more, see the ARIA specification and the APG Menu Button example.

Sliders

Most video players use a slider for the timeline. If there are detailed volume settings, you might find another slider for that too.

The slider lets users choose a point within a range, like 10 minutes into a 20 minute video.

Blind screen reader users must know:

• What the slider is for
• Know it is a slider
• What value it is set to, in context

What the Slider Is For

Even if your video player has only one slider, it still needs a name. Sighted users may see it as the timeline, but blind users will not know unless it is labelled.

Sliders often appear without a visible label, so the best option is to name it using aria-label.

Example with two sliders: one for the timeline, one for volume.

aria-label="Timeline"
aria-label="Volume"

Know It Is a Slider

Blind screen reader users must be able to recognise that a slider is a slider. This depends on how its role is conveyed.

There are two common approaches. One is a custom slider pattern, though support on Android has been patchy. The other is a native HTML input element. Both expose the correct role, but the native input offers wider accessibility support.

To convey the role with a native input, set its type to range. This automatically gives it the role of slider.

Simplified example of a native slider:

<input ...type="range">

What Value It Is Set To, In Context

Sliders let users pick a point within a set range by moving a thumb control.

Blind screen reader users need to hear the current position of the thumb, both when the slider loads and as it moves. They also need to know the minimum and maximum values.

This is handled using HTML attributes:

• min: the start of the range
• max: the end of the range
• step: how far the thumb moves with each change
• value: the current position of the thumb

Each attribute helps screen readers describe the slider clearly and accurately.

Simplified example of a thumb point half way through:

min="0" max="20" step="20" value="10"

Here’s how the complete slider might be structured:

<input 
  aria-label="Timeline"
  type="range"
  min="0" 
  max="20" 
  step="20" 
  value="10">

Let The Message Through

A status message is a short update that appears while something is happening. It tells the user what worked or what didn’t. You don’t need to press anything to remove it.

For example, on YouTube, pressing the RIGHT ARROW key while focused on the timeline nudges the video forward. A message like “5 seconds” appears with an icon, confirming the jump.

The main goal here is to make sure blind screen reader users can hear status messages.

To do this, apply role="status" to the container that holds the message. Because of a screen reader quirk, the role must be present for a few seconds before adding any content.

When used properly, screen readers will announce the message as soon as they can, without breaking the user’s flow. This works well for short updates like confirmations or small errors.

Simplified Example of a status message:

<div role="status"> Fast-forwarded 5 seconds </div>

Congratulations! Your Video Is Now Accessible to Blind People

Well done for completing our series!

Depending on how your videos were built, this may have been a long road and one that you can be proud of.

Please do not underestimate what you have achieved. Making your videos accessible to blind people is a meaningful step towards inclusive design. Be proud of that. Many people never even read about accessibility. You stayed the course. That matters.

If this series helped you, share your achievement on social media. Tag us with #TabAble or find us on LinkedIn under @tab-able. Let others know your video now works for blind people.

The post Episode 5: The Tree That Endures appeared first on Tab-able.co.uk.

This episode explores how to keep blind users oriented so they know exactly what just happened and what will happen next.

This is for curious readers, as well as Accessibility Experts, Developers, and Testers.

You know that feeling when you click a link and land on a “404 – Page Not Found”? You were expecting something familiar, something useful. Instead, you’re somewhere else entirely, with no clue how you got there. That’s what it feels like for blind users when a video player suddenly shifts them away.

Fortunately, these experiences are covered by accessibility guidelines.

The WCAG Principle Understandable includes 21 success criteria. But when we focus specifically on video players and blind users, only 4 are generally relevant.

Level A

• 3.2.1 On Focus
• 3.2.2 On Input

Level AA

• 3.1.2 Language of Parts
• 3.2.4 Consistent Identification

Specific to Video Players

To be clear, this guidance relates solely to video playback and its controls. If your video is decorative and has no controls, and you’ve met all criteria from previous episodes, congratulations, your video is accessible to blind users.

For everyone that has a video player, we need to consider that:

• Controls do not initiate unexpected changes of context
• Controls responsible for selecting language must present those languages with the correct pronunciation
• Multiple videos should have the controls in the same order

No Sudden Detours from the Player

When a blind user moves through a video player, and when they activate the controls, there must not be an unexpected change of context. Controls should behave in a predictable way that matches their design pattern.

Not all blind users have zero vision. The goal is to keep them with the video, not move them away. If they’re moved, their screen reader starts announcing unrelated content. They lose their place, cannot reach other video controls, and struggle to return.

For basic controls like “Play,” “Mute,” or “Fullscreen,” the expectation is simple. They should do what they say without shifting the user somewhere else. If someone presses TAB to reach the control, they should land on it and stay there. That’s standard behaviour and covered in the previous episode.

More complex controls like menus, timelines, and volume sliders need the same care. Pressing ARROW UP to increase the volume should do just that. It should not jump to another control or reset the user’s position. Screen reader users may also use touch, so gestures must behave predictably too.

Accessibility Criteria for This Interaction

1. Keyboard users can discover the pause and resume controls in a logical sequence.
2. Keyboard users can open the more options menu without losing their place or context
3. Keyboard users can discover and operate the timeline control without losing their place.

The Right Language for the Right Voice

This part isn’t about being left in the dark. But it does help when content speaks up in the right pitch.

If your video player offers caption options in different languages, each one must be pronounced correctly by screen readers.

This matters most for streaming services with multilingual subtitles. For example, when an English-speaking screen reader user hears the option “Français,” it should be spoken with the correct French pronunciation. That way, the user can understand it and choose confidently.

This can be achieved by adding the lang attribute with a relevant language code as its value:

<div ... lang="fr"> Français </div>

Keep the Layout Familiar

When videos appear on multiple pages, their controls must be identified consistently.

This means using the same accessible name every time. For example, a control labelled “Play” on one page should not be called “Continue” elsewhere.

This is easy to maintain when the video player is built as a reusable component.

Other Rules We Chose Not to Include

If you were expecting other success criteria to appear in this article, and they’re missing, we’d like to hear from you.

We’ve reviewed the following criteria and intentionally left them out. The reasons are explained below.

Avoid Interrupting the User Without Warning

We chose not to include the rule about interruptions in this article (2.2.4 Interruptions.) This rule is designed to protect screen reader users from unexpected updates that can disrupt their experience.

An interruption happens when something new is announced without the screen reader knowing. The screen reader may or may not pause its current speech. When it resumes, the user might find themselves further ahead in the content, with no clear way to return.

For example, on a stock exchange site, a live update might speak over a paragraph the user is reading. The screen reader continues silently, and when the update ends, it picks up again. The user has missed part of the content and cannot easily go back.

This issue does not apply in the same way to video adverts. These interrupt the video itself, not the screen reader. The screen reader stays in sync, and when the advert ends, the user resumes from the same point in the video.

Only Change Context When the User Asks

The rule about changes on request is designed to prevent unexpected shifts in context that users did not trigger (3.2.5 Change on Request.) We’ve already covered changes caused by keyboard focus or input. What remains are changes that happen without any interaction.

We do not believe video players introduce these kinds of shifts. Adverts may appear, but they play within the same player. A change in content is not the same as a change in context.

Adverts may also not be unexpected. Blind users are just as capable of understanding how streaming platforms use advertising as anyone else.

You’ve Met Principle Understandable for Blind Users

If you’ve followed all the criteria above, congratulations you’re 80% there. And if your video has no controls to begin with, that’s a valid approach too. Well done either way.

The post Episode 4: Preventing “Wait, What?” appeared first on Tab-able.co.uk.

Each episode supports a different group, from content creators to developers, and draws on the Web Content Accessibility Guidelines (WCAG), including its Principles, Guidelines, and Success Criteria.

The post Video Without Vision appeared first on Tab-able.co.uk.

A curated collection of accessibility series, each revealing expert techniques that show what inclusive design really takes

We’ve spent time writing, illustrating, and solving real accessibility problems to make this series useful and enjoyable. We offer it freely because we believe accessibility should be fun to learn and easy to share.

If you’ve enjoyed reading it, please pass it on. Share it with your communities and tag us using #TabAble. We’re listening, and we’d love to bring your ideas into future episodes.

The post A11y Series appeared first on Tab-able.co.uk.

Awareness of ADHD is growing, but many digital platforms still fall short.

One common issue is animation. Continuous movement can make it difficult for people with ADHD to focus, creating a serious accessibility barrier. For example:

• Gifs that loop without pause
• Pulsating buttons or parts of the page that are designed to attract attention
• Looping carousels that rotate automatically
• Adverts with flashing or moving elements

Some animations, like loading icons, can be necessary. Pausing them may suggest the page has frozen. In many cases, users who trigger a loading state are not engaging with the rest of the page, so the animation is unlikely to distract them.

Tip: Limit or Remove Animations

Animations can add flair, but they should never come at the cost of accessibility. If they create barriers for disabled users, the best option is to remove them. Where removal isn’t practical, keep them brief and easy to control.

Limiting animations to under 5 seconds can improve usability for people with ADHD. This is especially helpful for attention-grabbing elements, such as those designed to guide users toward key content.

There are several methods that support people with ADHD, though some are more dependable than others. The most effective approach combines multiple techniques to reduce distraction and improve focus.

Method 1: Honour Device Settings

Respecting device settings is one way to support users with ADHD, though not all users will have these settings enabled.

Websites can use the prefers-reduced-motion setting to detect when a user has asked for less movement. This does not stop animations. It only asks for them to be reduced.

However, if motion continues, even in a softer form, it may still cause problems for users with ADHD. Relying on this setting alone may not be enough.

Here is an example of how to use the reduce motion setting to turn off animations entirely:

@media (prefers-reduced-motion: reduce) {
  .animation {
    animation: none;
  }
}

Method 2: Providing Individual Settings

If animations are limited to a few areas, it may be simpler to offer pause and resume controls for those sections. This is commonly used with autoplaying carousels.

A standard HTML button can trigger scripts that pause the movement. For example:

Simplified Code Example:

<button> Pause Carousel </button>

Method 3: Providing Global Settings

If multiple animations are used, a global setting may be more effective. Like a Cookie banner, it can give users control over animation preferences across the site and be recalled after dismissal.

One approach is to include a checkbox within a dismissible banner shown on one or all pages.

This banner must be easy to find when an animation occurs. Users need to know it exists and understand how to reach it. Making that connection clear is a design challenge. It is difficult to achieve without placing a visible control on every animated element.

The banner should be easy to reopen, allowing users to change their preferences when needed. For example:

Simplified Code Example:

<section aria-labelledby="region1-name">
  <button id="region1-name" aria-expanded="false" aria-control="region1-content"> Movement Preferences </button>
  <div id="region1-content" style="display: none">
    <label for="control1">
      <input id="control1" type="checkbox">
      Animations
    </label>
  </div>
</section>

Technical note: the control to reveal preferences is placed within a region landmark to improve findability for those using screen readers.

Our Recommendation

WCAG ADHD Requirements

People with ADHD are supported under WCAG Success Criterion 2.2.2 Pause, Stop, Hide.

To meet this criterion, one of the following must apply:

• The movement does not run continuously for more than 5 seconds
• The movement can be paused, stopped, or hidden
• Auto-updating content can be paused, stopped, or hidden

There is an exception for movement that is essential to understanding the content. If removing the movement would change the meaning, it may be considered essential.

Resources

• [WCAG] SC 2.2.2 Pause, Stop, Hide

The post A11y Tip: Designing For ADHD appeared first on Tab-able.co.uk.

If you’re designing content only for landscape or portrait you might be limiting access for your intended audience.

This approach may unintentionally exclude users with disabilities, including those with dexterity challenges or low vision.

The use of CSS media queries such as landscape or portrait could be contributing to the accessibility issue.

Accessibility Issue

Websites that force portrait or landscape mode can make it hard for people who can’t rotate their device or prefer a certain view.

Messages that ask users to rotate their device generally obscure content and limit access.

Who Is Affected

People with Dexterity Impairments

People whose devices are physically mounted to wheelchairs or who lack the ability to rotate them.

People with Low Vision

People with low vision who zoom in from a landscape monitor to improve readability.

Accessibility Tip

Avoid restricting your website to a single orientation.

Content should be usable in whichever orientation the user has chosen.

A common design misstep is starting with desktop as the default.
It’s tempting to use all that space and build complex layouts that depend on multiple elements being visible at once.

To prevent these issues from surfacing later, begin with a mobile-first mindset.
And when you do, make sure to support both orientations from the start.

As the designer or developer, you have the creative freedom to make your site inclusive without compromising functionality.

Modern design techniques allow content to adapt to smaller or differently shaped screens.

There is rarely a technical reason to restrict orientation completely.

WCAG Orientation Requirements

Orientation restrictions are generally not compliant with WCAG standards.

Exceptions apply only when content cannot function in another orientation, such as piano apps or VR interfaces.

Note: Examples where a particular display orientation may be essential are a bank check, a piano application, slides for a projector or television, or virtual reality content where content is not necessarily restricted to landscape or portrait display orientation.

To ensure accessibility, it’s best to avoid enforcing orientation restrictions. These limitations are rarely necessary for most websites and can create barriers for users.

Resources

• [WCAG] SC 1.3.4 Orientation
• [Example of orientation restriction on portrait] Victorian Women’s Health Atlas

The post A11y Tip: Device Orientation appeared first on Tab-able.co.uk.

If you’re using CSS properties like text-overflow:ellipsis to force horizontal alignment, that may be the source of the accessibility issue.

Accessibility Issue

Truncated text can break context for users who zoom or adjust spacing, leaving them with cut-off content and no way to access the full message. What others see as a design choice, they experience as a barrier.

Who It Affects

• People with cognitive disabilities that increase text properties such as letter-spacing and word-spacing.
• People with low vision that increase the size of text or magnify the page.

Accessibility Tip

Avoid constraining information with ellipses or truncation. Let text wrap naturally, it’s how the web is designed to work.

If truncation is essential, set a fixed word limit so the same content is truncated for all users. Use HTML to apply the ellipsis after the set number of words, ensuring consistency across devices, zoom levels, and user settings.

WCAG Truncation Requirements

Truncation is generally non-compliant unless users can access the full content.

For example, an email subject line may appear truncated at first, but expands to reveal the full content when activated.

People with low vision and cognitive disabilities are covered in multiple WCAG Success Criteria (SC):

• SC 1.4.4 Resize Text: information cannot be lost if people choose to zoom in 200% from any responsive version of the page.
• SC 1.4.12 Text Spacing: information cannot be lost if people choose to modify text properties to a range specified in the criterion.

Resources

• [WCAG] Success Criterion 1.4.4 Resize Text
• [WCAG] Success Criterion 1.4.12 Text Spacing

The post A11y Tip: Truncating Text appeared first on Tab-able.co.uk.