Accessibility Tips

Mobile App Accessibility and Visual Content

Mobile app accessibility is essential, yet many apps still fall short. A recent report found that only 29.9% of screens include proper alt text, significantly limiting how well screen reader users can understand visual content, particularly when images contain embedded text or important labels.

In mobile development, providing text alternatives is platform specific. On Android, developers use the contentDescription attribute to expose meaningful descriptions to assistive technologies. On iOS, the equivalent is the accessibilityLabel property. These labels are what screen readers like TalkBack and VoiceOver announce to the person using the app.

For example, imagine a streaming app with a promotional banner that visually displays: “New Release: The Latest Adventure – Watch Now.” If that banner image has no accessibility label, a screen reader may announce nothing at all, or simply “image.” The person using a screen reader would have no idea that new content is available. Instead, the image should have a meaningful label such as: “New release, The Silent Horizon, button, watch now.”

At the same time, purely decorative images should not be announced. An ornamental divider icon or background flourish adds visual design but no meaning. On Android, this can be hidden from assistive technologies using android:importantForAccessibility="no". On iOS, developers can set isAccessibilityElement to false. This prevents unnecessary noise and keeps navigation efficient for screen reader users.

The key principle is simple: if an image communicates information or triggers an action, that information must also be available programmatically. Without proper accessibility metadata, entire features of a mobile app can become invisible to people who rely on assistive technology.

Want to learn more about mobile app accessibility? Check out our training course Accessibility for Mobile Apps.

Auto-Playing Audio

Unexpected sound on a webpage is one of the quickest ways to create an accessibility barrier. Auto-playing audio can interfere with assistive technology, overwhelm people with sensory or cognitive disability, and make it difficult for anyone to concentrate on the surrounding content.

WCAG 1.4.2 Audio Control (Level A) addresses this by requiring that if any audio on a webpage plays automatically for more than 3 seconds, users must be given a way to pause or stop it, or a separate mechanism must be provided to control the audio volume independently from the device’s overall volume settings.

This includes:

• Background audio on a landing page
• Auto-playing audio in an embedded media player
• Intro music on page load
• Auto-reading text or narration that starts on load

Auto-playing audio is particularly problematic for people who use screen readers because the speech output competes directly with the audio, making the content unintelligible. It may also affect people with ADHD, sensory processing disability, or anyone browsing in a shared or quiet environment!

The most accessible approach is simple: avoid auto-playing audio all together. If for some reason audio must begin automatically, always ensure that:

• A visible, clearly labelled control is provided to pause or stop the sound
• The control is keyboard accessible
• Volume can be adjusted independently of system controls if pausing is not an option
• Audio does not restart automatically after being stopped
• Audio controls are available at the point where the sound begins

Captions

Videos without captions exclude people who are Deaf or hard of hearing (as well as anyone who may be in a noisy environment or watching without sound). Captions make video content accessible by providing a text alternative for both spoken dialogue and meaningful sounds, such as laughter, music, or alerts. This ensures that everyone can understand the full context of your content, not just those who can hear the audio.

Under the Web Content Accessibility Guidelines (WCAG) 2.2, captions are a key requirement for making multimedia accessible. Specifically:

• 1.2.2 Captions (Prerecorded) (Level A) requires captions for all prerecorded audio content in synchronised media.
• 1.2.4 Captions (Live) (Level AA) extends this requirement to live video streams, such as webinars or broadcasts.

While many platforms now offer automatic captioning tools, these are often inaccurate. They often miss words, fail to identify speakers, or omit important non-speech sounds. Automatic captions can provide a useful starting point, but they must be reviewed, edited, and synchronised before publishing to meet accessibility standards and ensure a quality viewing experience.

Ensure that any captions you create also have sufficient colour contrast between the text of the caption and any background to at least 4.5:1. 

Captions also offer broader benefits beyond merely WCAG conformance. They improve comprehension for people in noisy or sound-sensitive environments and support language learners. In other words, providing captions isn’t just good accessibility practice, it’s good design!

Don’t Rely on Colour Alone

Colour is a great way to add visual clarity, but when colour is used as the only indicator, it can create serious barriers for people who are colour blind or people who have vision disability. An estimated 1 in 12 men and 1 in 200 women experience some form of colour blindness, so relying only on red, green, or other colour differences excludes a significant part of your audience.

This principle is covered in WCAG Success Criterion 1.4.1 (Use of Colour), which states that colour must not be the sole method of conveying information. Designers and content creators need to provide additional cues so that meaning is always available in more than one way.

Mandatory Fields and Error Messages

A common example is marking mandatory form fields in red. If the only difference between required and optional fields is a red border or label, someone who can’t perceive red/green differences won’t know which inputs are required. Instead, pair the colour with text (e.g. adding the word “Required” beside the field label) or with a visible symbol such as an asterisk that is explained clearly at the top of the form.

Another example is in error messages. Showing only a red outline around a box or a red highlight bar is not enough. Make sure to also provide a descriptive error message, like “Please enter a valid email address”, alongside the visual cue. This benefits everyone, not just those with vision differences.

Charts and Data Visualisations

Charts and data visualisations are another frequent issue. Using only colour to distinguish between categories, like red and green lines or bars in a graph, makes the information inaccessible. Add patterns, labels, or icons to differentiate the series, so the meaning doesn’t depend on colour alone.

Add Additional Information

By combining colour with text, symbols, or patterns, you not only meet WCAG Success Criterion 1.4.1 (Use of Colour) but also improve clarity and usability for all users.

Using Emojis

Emojis can add personality and visual interest to written content, but when it comes to accessibility, less is more. Use them sparingly and avoid replacing words entirely with emojis, as not everyone will perceive them in the same way. Screen readers will read out each emoji’s description, which can interrupt the flow of the content or make it harder to understand.

If you do use emojis, place them after the text rather than before, and make sure your message is still clear without them. Being mindful of how emojis are read aloud helps ensure your content remains clear, inclusive, and easy to understand for all readers, including those using assistive technologies.

Not all Headings are Created Equal

When it comes to accessibility, headings aren’t just about making text bigger or bolder, they’re about structure and meaning.

Using semantic headings (like Heading 1, Heading 2, etc.) in documents and web content is essential for people who use assistive technology and without this, they may miss important sections entirely.

Use built-in heading styles (e.g. Heading 1, Heading 2) to mark up heaidngs, keep the order logical and don't skip levels (e.g. jumping from H1 to H3) and use only one Heading 1 per page or document to define the main title.

Want to learn more? Take a look at our upcoming training on document accessibility.

Using Hashtags on Social Media

Hashtags are a great way to boost reach on social media—but they can also create accessibility barriers if not formatted correctly.

Make your hashtags easier to read and understand by using camelCase—capitalising the first letter of each subsequent word (e.g. #digitalAccessibilityTip instead of #digitalaccessibilitytip).

This simple practice helps those who use screen readers and improves readability for everyone, especially people with visual or cognitive disability.

Looking for more social media accessibility tips? Take a look at our Accessible Social Media Checklist.

Minimum Target Size

Small or tightly packed touch targets on websites, especially on mobile, can make navigation challenging for everyone — and for people with mobility or dexterity disabilities, they can make a site unusable.

WCAG recommends a touch target size of at least 44x44 pixels. If this isn’t possible, the Target Size (Minimum) success criteria requires a minimum target size or spacing of 24x24 pixels.

This helps maintain adequate size and spacing between interactive elements, reducing confusion and accidental activation of the incorrect element (for example, activating the delete instead of the save button!).

Meaningful sequence

Often designs place content before the headings it relates to, using visible proximity to show the relationship. Users who cannot see the screen do not have access to this information, therefore it can cause confusion and misunderstanding about the content.

For instance, a date or category of a news story may be placed before the heading visually, but for a screen reader user this would imply that the date and category belongs to the previous heading instead.

Ensure content that relates to a heading comes after the heading in the code to maintain its meaning.

Error Messages

Error messages should be clear, specific, and easy to understand. When users make a mistake—such as entering an incorrect password or forgetting to fill out a required form field—simply stating "Error" or "Invalid input" isn’t helpful. We’ve all probably experienced this, and for many people with disability such as those with cognitive disability, it makes interacting with a website incredibly difficult.

Instead of providing vague guidance as to the existence of an error, provide guidance on how to fix the issue. For example, instead of saying "Invalid password," a better message would be "Your password must be at least 8 characters long and include a number."

This is an example of a way in which you can conform to WCAG criteria 3.3.3 Error Suggestion (AA) and 3.3.1 Error Identification (A).

This is also an example of where conforming to accessibility principles within WCAG improves a user experience for everyone.

Document Accessibility

Accessibility isn’t just about websites—documents also need to be accessible.

A survey found that 90% of the trillions of PDFs online are not accessible. Many Microsoft Word documents also lack accessibility features, making them difficult or impossible for people with disability to navigate.

When creating documents, there are simple steps you can take to improve accessibility. One key practice is using proper headings. Headings provide structure, making it easier for people using assistive technology to navigate your document. However, they must be correctly marked up—otherwise, screen readers won’t recognise them as headings.

In Microsoft Word, use the Styles pane to apply built-in heading levels (Heading 1 to Heading 6). In InDesign, ensure the correct Export Tagging is set for headings.

There are many aspects to document accessibility, but proper heading structure is a crucial part of an accessible document.

ARIA

You may be familiar with Accessibility Rich Internet Applications, or ARIA. It is a is a set of roles and attributes that define ways to make web content and web applications more accessible to people with disability.  It’s a very powerful tool, but did you know that the first golden rule of ARIA is to not use ARIA?

In situations where semantic HTML elements can be used, they should be. This is because they have a range of accessibility features built in, which isn’t the case with ARIA.

Page Titles

Page titles help users identify and distinguish different pages across a website.

When creating page titles put the most important information first that reflects the content or purpose of the page, followed by the site name.

For example, a page containing a step in a multi-step checkout process for our TTC Global Shop site, the page title could be: ‘Step 1: Enter your details - TTC Global Shop’.