Accessibility Statement.

1. Introduction: Element’s commitment to accessibility

At Element, we are committed to making our products accessible to everyone, and that means designing our products with every kind of user in mind. This includes designing our web and mobile platforms so that they’re usable by everyone.

This accessibility statement outlines how our products align with accessibility standards, what limitations remain, and how users can report issues or request assistance.

Accessibility is not just a legal requirement under the European Accessibility Act (EAA), but a core part of what Element does; building inclusive, user-friendly communication tools for all.

2. Accessibility Explained

A lot of the terminology used here can be quite confusing and technical, so this section is intended to simplify and demystify the jargon, and make it clear what we are trying to achieve:

Accessibility in this context means designing products so everyone can use them, including people who use screen readers, can't use a mouse, have visual or hearing impairments, or require assistive technologies in order to use the product.

What is the European Accessibility Act (EAA)? This is a European Union (EU) directive that came into force in June 2025. It requires businesses that sell digital products or services to the public in the EU to make their platforms accessible. Some of its technical requirements are based on a mix of international standards, particularly WCAG and EN 301 549 (defined below).

What does conformance mean? This just means whether a product meets accessibility standards. “Full conformance” means it meets all criteria, whereas “partial conformance” means some parts are still being worked on.

What’s a WCAG? WCAG is just the acronym for Web Content Accessibility Guidelines. These are internationally recognised guidelines covering perceivability (information and user interface components must be presentable to users in ways they can perceive), operability (user interface components and navigation must be operable), understandability (information and the operation of user interface must be understandable), and robustness (content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies). “Level AA” is the standard that we, along with the majority of commercial organisations, try to achieve - removing the most common barriers people deal with when using products like ours.

What is EN 301 549? EN 301 549 is a European standard that specifies accessibility requirements for information and communications technology products and services. It builds on WCAG and adds requirements that are specific to software, documents, and user interfaces on various platforms.

What’s a VPAT (Voluntary Product Accessibility Template)? Essentially a formal accessibility conformance report that shows how our products meet each WCAG and accessibility requirement.

3. Accessibility standards

We are working towards compliance with the EAA. As is the case with most rules and regulations, the governing bodies setting out these requirements are constantly reviewing and updating their guidelines. This means that any assertion regarding our accessibility conformance is a commitment to remain up-to-date with these evolutive requirements as much as we can, with the resources we have available. We therefore design and test our products in line with the EN 301 549 standard, which also incorporates the WCAG 2.1 Level AA criteria. Please see more information around the platform-specific requirements we are working towards in section 4 below.

Our approach to achieve full conformance with the standards

At Element, we are fully committed to continuous improvement and perfecting accessibility across all our platforms. This is an ongoing effort to maximise accessibility, and it's at the forefront of our minds when designing, building, and testing our products. Actions speak louder than words, so here are some of the things we’re doing:

  • Reviewing features during development to catch accessibility issues early.
  • Working proactively with the screenreader community.
  • Regularly testing our web, mobile, and desktop applications using both automated tools and manual evaluation.
  • Fixing issues based on audits, user feedback, and internal quality assurance cycles.
  • Keeping our team informed on accessibility practices through consistent training and development of internal documentation.
  • Automated testing performed on each release every other week.
    • End-to-end manual testing occurs every 6-12 months.

Accessibility improvements are tracked, prioritised, and re-evaluated with each product update to ensure we stay aligned with evolving standards and user needs. If you have any suggestions or encounter any accessibility-related issues on any of our platforms, please don’t hesitate to reach out to us – your feedback is vital to help us in our mission to make our products accessible to everyone. You can learn more about this process in section 5 below (it doesn’t just apply to complaints).

4. Accessibility: Platform Breakdown

Element Web

Specific features include, but are not limited to:

  • Supports text alternatives provided for system icons 
  • Use ARIA roles and landmarks, along with descriptive labels, for screen read compatibility
  • Light/dark and high-contrast mode available
  • Text resizing and scaling available, along with the ability to change font for improved legibility

Compatibility and browser support

Element Web is built for current versions of major browsers (e.g. Chrome, Firefox, Safari, Edge). 

Scope of application

Our current priority is on making our commercial products as accessible as possible, as soon as possible, while applying our best efforts to do the same for the open-source versions of those products. We cannot make any commitments regarding third-party widgets which we do not control, so they are out of scope.

Legal requirements

Element Web is developed to meet EN 301 549, which incorporates the WCAG 2.1 Level AA criteria, both of which form the basis of the technical requirements of the EAA.

Known issues

  • Alternative text for media messages: Users are not currently able to provide alternative text for media messages they share - we recognise that media captions would improve the user experience.
  • Emoji picker: There is currently a bug causing a partial keyboard trap for the emoji picker in the composer. This is currently being fixed by the team. Users caught by this bug can exit the emoji picker using the ESC key.
  • Error identification: Due to the sometimes complex relationship between the Matrix protocol and its clients, some error messages are not using the Element voice and tone and can be hard for end users to understand. Element has drafted and is pursuing a spec change (MSC4183 & MSC4178) to resolve specific error cases identified so far, and will continue to monitor, log, and address any remaining scenarios. 

Element Mobile

Unless specifically noted, the features and known issues detailed below refer to both the Android and iOS mobile platforms. 

Specific features include, but are not limited to:

  • VoiceOver and TalkBack support
  • Dynamic Type and Android Accessibility Settings support
  • Ensured touchable target sizes
  • Support for light and dark mode
    • iOS provides two high-contrast themes as a system setting, while Android relies on the OS contrast setting.

Compatibility and browser support

On iOS, we support the two (2)  previous versions of available software from Apple. For example, in the summer of 2025 we support iOS 17 and iOS 18. From September 2025 onwards we will support only iOS 18 and iOS 26.

On Android, Element Pro (and its variants) is only supported on OS versions still receiving regular Google security updates (https://endoflife.date/android). Element X supports older devices from Android 7.0 Nougat onward. You can read more about the supported versions here:https://github.com/element-hq/element-x-android?tab=readme-ov-file#minimum-sdk-version 

Scope of application

Our current priority is on making our commercial and latest products as accessible as possible, as soon as possible. We cannot make any commitments regarding any legacy or unprioritised apps.

Legal requirements

Element Mobile on iOS and Android is developed to meet EN 301 549, which incorporates the WCAG 2.1 Level AA criteria, both of which form the basis of the technical requirements of the EAA.

Known issues

  • Alternative text: We've identified a few issues on how alternative text is handled for images like profile pictures and room uploads. We are actively working on rectifying this.
  • Heading structures: We're reviewing and correcting heading structures to make sure they’re labeled clearly and consistently. 
    • For example: In some cases, screen readers repeat content unnecessarily and on Android improving how information is communicated by screen readers from the room list is a priority.
  • Emoji verification: We’re working on clearer messaging around emoji verification, including timeouts and alternative ways to verify a device.
  • Consistent orientation: We're updating how focus behaves after navigation actions—like jumping to the latest message—so users stay oriented in the app.
  • Polling improvements: We're enhancing how polls are communicated to users, so that changes like switching options are clearly conveyed—multi-select support is also on the way.

5. Complaints procedure

If you encounter an accessibility related issue, you can escalate your complaint as follows:

Step 1 – Contact the team

  • Email: [email protected] 
  • Response target: 30 days from the date the issue was raised.

Step 2 – Request an internal review

If you are unhappy with the initial reply, ask for your case to be reconsidered by our team.

  • Review target: Within 30 days of the date of the initial response.

Step 3 – Independent advice or external escalation

Depending on where you are located, you may have different options in order to escalate your complaint. Users based in the UK can access Equality Advisory and Support Service (EASS) for free, impartial guidance on these issues. You can find the relevant link here: https://www.equalityadvisoryservice.com/  

For users based in the EU, you may raise the matter with the relevant national authority responsible for the EAA in your country. Please see the list of these bodies here: https://digital-strategy.ec.europa.eu/en/policies/web-accessibility-monitoring?

6. Compliance Reports

Making sure our products are accessible as possible also means being transparent about our methods. To this end, we produce formal accessibility conformance reports (also known as VPATs) to provide detailed breakdowns of how each of our platforms measure up against both WCAG 2.1 AA and EN 301 549. Please reach out to [email protected] to request a VPAT and see if you meet our internal criteria to receive these.

7. Review schedule

We will continuously review and republish this statement annually, or sooner if there are significant product or regulatory changes that we need to address.

Document History

  • 7th July 2025: Initial publication 1.0
  • 8th July 2025: Fix typos 1.1