New Threads app fails accessibility test

With over 100 million users signed up in its first five days, Threads is the fastest-growing social network ever launched – but is why is Meta excluding millions of possible users by repeating the accessibility mistakes of the past?

WSmart phone on laptop displaying the Threads apphen Meta’s Instagram team launched Threads this month, millions of users flocked to the new Twitter competitor, to see if it lived up to founder Mark Zuckerberg’s claim that they would be “focusing on kindness and making this a friendly place”.

But, however friendly the tone of the content shared on the site may be, Threads is excluding disabled users as the new mobile-only app has launched with many accessibility issues.

Meta’s Threads launch announcement, claimed that “The core accessibility features available on Instagram today, such as screen reader support and AI-generated image descriptions, are also enabled on Threads” – but our testing suggests otherwise.

AbilityNet’s expert accessibility and usability consultant, Paul Speller carried out a brief accessibility audit of just one page – the main Threads home timeline – on an Android device, against WCAG 2.1 Level AA. The Web Content Accessibility Guidelines (WCAG) define a set of standards for how websites and apps can be built more inclusively, breaking down barriers for all disabled users.

The results are not very kind or friendly.

Of around 30 relevant WCAG Success Criteria he tested, he found multiple failures on around half the criteria, creating access barriers for millions of potential Threads users.

These are the key usability features tested:

  • Images
  • Headings
  • Navigation
  • Buttons
  • Reloading the timeline
  • Colour contrast
  • Media
  • Orientation

Threads presents issues for screen reader users

A screen reader allows people who are blind or visually impaired to use their computer and mobile phones and the Threads app presents many issues for these users.

Inaccessible images

Most obviously, there is no way for users to provide alternative text descriptions (alt text) for their images when creating a post or reply.

This is a basic battle that users have had with all the older social networks and eventually had this feature added to most of them.

Meta claims their artificial intelligence (AI) engine can describe images automatically, but in our testing, the results were generally poor: it’s difficult or impossible for an AI engine to understand the intention an author has when they include an image.

Screenshot from Threads homepage with a post from Scottygb showing a photo of framed certificate with unhelpful AI-generated alt text "May be an image of text".

Figure 1: Photo of framed certificate has unhelpful AI-generated alt text

The worst AI-generated description we encountered simply said “May be an image of text”. Even if the photo hadn’t shown a framed certificate with text on it, the text within the image would have been needed to understand it, not just the fact it was some text.

It’s not just the images users provide that need alt text.

Meta provides a ‘verified’ blue tick badge next to some users’ names, for sighted users to be assured they are who they say they are. These badges have no text alternative provided and are not announced by a screen reader at all, so visually impaired users will not get that same reassurance.

Other problems our screen reader testing encountered included:

No headings

No text anywhere in Threads that we’ve seen is marked up as a heading.

This removes one of the key ways assistive technology users can navigate within the pages of an app (failing the Info And Relationships WCAG Success Criterion).

Navigation issues

When the user opens and then closes a pop-up menu, they are thrown onto an irrelevant element somewhere else on the page.

This is likely to cause confusion and difficulty navigating the app (failing the Meaningful Sequence Success Criterion).

Illogical post order

In certain scenarios, the order in which the parts of a post on the home timeline could be accessed was very chaotic, jumping around various elements of the post’s information and content. It even jumped backward into information about the previous post while navigating through the current post (see numbered order in the image below).

It’s important that assistive technology users can tell which post each piece of information relates to, and this illogical order makes this near-impossible. (This also fails the Meaningful Sequence Success Criterion.)

Screenshot of the Threads homepage and the order in which each element received the screen reader cursor when navigating through a post in the Threads home timeline. The sequence is not meaningful, and at one point the order jumps back to the ‘Likes’ information from the previous post.

Figure 2: The order in which each element received the screen reader cursor when navigating through a post in the Threads home timeline.

The sequence is not meaningful, and at one point the order jumps back to the ‘Likes’ information from the previous post.

Button trouble in Threads

There were also numerous failures with the way Threads page elements were announced, for instance with lots of buttons not having a “button” role to ensure users could understand their purpose.

For sighted users, it may be obvious which things on screen look like you could tap them to load new pages or perform actions, but this must be communicated to assistive technology users, for example by giving them a button role. Every time this has been omitted, it’s a failure of the Name, Role, Value Success Criterion.

The addition of a “+” button to the icons for users who appear in your home timeline, but you don’t yet follow has been praised by sighted users for its simplicity and ease of use. But sadly this has not translated into good code for accessibility.

The icon button’s name is the same as the user’s name, which is already next to it, creating repetition; but also the word “Follow” only appears at the end of what sounds like it will just be a standard Android screen reader “Double-tap to activate” announcement, after a delay: “Username… Double-tap to follow”.

Users may choose to move on before hearing this crucial word, so it has the potential to confuse them by not making the purpose of the button clear up front, as a good accessible name should. This could also cause issues for speech recognition users, who may try to activate what appears from the “+” to be a button called “Add” or “Follow” but whose name does not contain this – a possible failure of the Label In Name Success Criterion.

A better approach here would be to ensure the on-screen username text is read first, then the icon is either hidden if it does not have a ‘+’ on it, or is read as “Follow [username], button” if it does have a ‘+’ on it. This would reduce duplication while ensuring the following functionality is clear to all users.

Reloading difficulties in Threads

Perhaps most strangely, the Threads icon at the top of the page is exposed to assistive technology as “Progress bar, in progress”.

The icon does indeed animate when the page is reloading, but it never shows how close it is to finishing loading so it’s not a progress bar and the “in progress” state is there at all times, including when the page is not currently reloading. Users of assistive technology will be told this is a progress bar and that it is in progress when in reality it is neither.

The logo also cannot be activated to reload the page when using a screen reader: the only way to reload is to go to the “Home” icon and activate this, but there is no information to tell users this. Without the “Home” icon, this would be a failure of the Pointer Gestures Success Criterion; as it is, it could be a lot clearer for users.

Meanwhile, when the page was reloading, the app failed another Success Criterion (Status Messages) by not declaring this fact to assistive technology. Users have no way of knowing the page is reloading, and no way to know when it had finished doing so either.

Threads colour contrast problems

It’s not just screen reader users who will have issues using Threads. Other accessibility failures will affect other users too.

Users with low vision will struggle with elements of the app because it fails both the WCAG Success Criteria relating to colour contrast (Contrast (Minimum) and Non-Text Contrast). These require that regular-sized text must have a contrast ratio of 4.5:1 with its background, and non-text elements a ratio of 3:1. For example:

  • The numbers of Replies and Likes are in grey text on a white background, with a contrast ratio of 2.8:1.
  • Links in posts are light blue on a white background, with a contrast ratio of 3.2:1.
  • The non-current icons on the navigation bar at the bottom of the app are grey on a white background, with a contrast ratio of 2.1:1.

Screenshot of Threads homepage with several elements of the timeline page having insufficient colour contrast against the white page background

Figure 3: Several elements of the timeline page have insufficient contrast against the white page background

Media issues

Despite the work Instagram have done to help users generate captions automatically for their Stories and Reels, Meta has not yet provided any captioning functionality at all for videos within Threads.

To comply with WCAG requirements around captioning (Captions (Prerecorded)), users will need to generate their captions elsewhere and burn them into their video before importing them into Threads. This manual process is likely to be a barrier to the provision of captions on many videos, excluding d/Deaf users and disadvantaging the many other users who may be using the app with their phone sound off and also relying on captions.

Ironically this must have been the process the Head of Instagram went through to create his video with captions listing all the top new features they’re working on adding to Threads – none of which was captioning!

Threads also doesn’t provide any features for audio descriptions and transcripts (required by Success Criteria such as Audio Description or Media Alternative), but sadly it is still common for these to be missing from even the most developed social networks.

Nevertheless, wouldn’t it be nice to see a new service launching to meet all of WCAG, instead of joining the others who overlook these parts?

There is also no way to pause a video without losing access to the rest of the app: you have to open the video, then put it on full screen, then tap it, to be able to pause it, and as soon as you back out of that situation it resumes playing. This means the app also fails the Stop, Pause, Hide Success Criterion, disadvantaging users for whom unstoppable motion can trigger a reaction.

Portrait-only orientation 

There’s also one straightforward failure not yet mentioned: the app fails the Orientation Success Criterion because it only works in portrait orientation. This automatically excludes users who want to access Threads through a landscape-oriented mounted touchscreen device that cannot be rotated, for example.

Learn more about the requirements of web orientation for accessibility in the below video:

Threads launch fails to prioritise accessibility

All of the above adds up to a very disappointing start for Threads on the accessibility front – and that’s just from a quick one-page audit.

After fixing the issues identified here, the next step should be for Meta to work with real users of the app with diverse needs and get their feedback on how well it works for them.

It’s always easier to build accessibility into apps, websites, and other digital content from the start, rather than trying to retrofit it later. It shouldn’t be incumbent on disabled users to have to speak up to get these problems fixed, but it frequently has been and seems like it may be again here.

For now, there’s a long way to go before all users can feel welcomed into Meta’s supposedly “friendly and kind new social network”.

Looking for help with accessibility?

AbilityNet champions accessible, inclusive design. Our Accessibility Services help you to reach every customer on every platform, and our experienced consultants can audit and help you to build accessible apps and website.

Our affordable, expert-led training gives your team the skills they need, from wireframes and design reviews to accessibility testing and development. 

Not sure where your organisation is with accessibility? Download our free Digital Accessibility Maturity Model.

Training: Accessible mobile development

 

Learn how to include accessibility when building a mobile application.

Further resources

AbilityNet provides a range of free services to help disabled people and older people. If you can afford it, please donate to help us support older and disabled people through technology.