Wysa Accessibility Statement

At Wysa, we leverage technology to meet people where they are and make caring for mental health and well-being easier for everyone. We take our ethics, environmental and social responsibilities very seriously as we strive towards our mission.

Our app and website is partially compliant with the Web Content Accessibility Guidelines (WCAG) version 2.1 A-AA standard requirements.

We design our products and services with accessibility and inclusivity in mind.

Wysa’s ethos is that everybody should have access to quality wellbeing support in a way that suits them and we work closely with users from all over the world to ensure Wysa incorporates and reflects the views and needs of a variety of people. From clinical professionals to everyday members of the public we take your feedback very seriously and use it to help our product grow. We use comments left for us in the app store or in feedback to the app to help make important changes and we set up specialist co-design groups to help us support our research projects. We also use usability testing insights from User testing platform to find pain-points and uncover opportunities to improve. We have incorporated feedback from various user groups like students, caregivers, under-represented communities, differently abled people/disabled people and people living with chronic conditions.

User feedback is collected and integrated into app design and development on a continuous basis. These include:

1. By way of usability testing
2. Beta tester feedback prior to release
3. User feedback submitted in play/app store reviews or those sent to our corporate email

We do usability-testing where we engage with users when:

• We are working on a new feature and we need to validate if it really solves the problem it intends to solve.
• We need to validate a new flow we have designed in the experience.
• We want to validate how a conversation with the chatbot performs.
• We have worked on a revamp in the product and want to ensure it is performing as expected.

Remote Usability Testing processes are integrated into our product development cycle through User Testing platform. In our usability-testing sessions,

• We create and release a testing plan in which we assign to users different tasks using one or more specific user interfaces.
• We ask participants to perform tasks, usually using one or more specific user interfaces from design prototypes or app builds. While the participant completes each task, we observe the participant’s behaviour and listen for feedback.
• We analyse the information, extract insights and define recommendations to improve the design/product.
• Then we move into another iteration phase based on those insights.

To ensure our user interface, user experience design and visual design are more accessible to people with varying abilities, but also to anyone who is experiencing a permanent, temporary, or situational disability, we align to WCAG 2.1 guidelines. We assess every year our designs and components against Level A and AA success criteria.

These are the WCAG requirements we take care of:

1. For both web and apps:

• Provide sufficient contrast ratio between foreground and background so that all users should be able to read the text on our app/website and determine what our app/web page elements are supposed to do. Contrast rules for text ensure both large and small text is accessible. For large text we provide a minimum contrast ratio of 3:1. For small text we provide a minimum contrast ratio of 4.5:1.
• Provide clear and consistent navigation options so that the different parts of our app/web page are easy to locate and identify.
• Use headings and spacing to group related content reducing clutter, and making it easier to scan and understand.
• Ensure designs work for different viewport sizes making it easier to read and navigate the content on different screen sizes.
• We ensure colour contrast in our Website

1. Specific to mobile apps

• We provide support to visually impaired people via TalkBack (Android) and via VoiceOver (iOS) for most of the components (includes non-textual content such as images and GIFS), providing spoken feedback so that people can use the app without looking at the screen.
• We make use of an iOS feature VoiceControl to enable the user to navigate through the app by using voice which will help people with motor control impairment to use the app comfortably.
• Users can change from light theme to dark theme the app to help reduce the luminance emitted by device screens, while still meeting minimum colour contrast ratios. Dark theme improves visual ergonomics by reducing eye strain, adjusting brightness to current lighting conditions, and facilitating screen use in dark environments – all while conserving battery power.
• Based on user's selection at OS level for Android (phone's accessibility features) font size changes and display size changes in the app, for iOS only in Wysa and therapist chat bubbles font size changes.
• Our audio-video tools have a mechanism to pause or stop the audio at any time and have captions available for them..
• We allow users to control time limits on their reading or interaction. We apply this criteria in pause breathing tools and breathing animation splash screens.
• We make the placement and functionality of content predictable. We apply this criteria in our menu, back controls, skip navigation controls, CTA buttons in toolpacks.
• We also follow Apple iOS and Google Android provided design guidelines and best practices and check adherence prior to app releases.
• Title, headings and labels are descriptive and labels are clearly mentioned.

We also follow Apple iOS and Google Android provided design guidelines and best practices and check adherence prior to app releases.

The following are not accessible but are being addressed today.

1. Our Website: We tested our website (Wysa - Everyday Mental Health) using Google Lighthouse. The following opportunities to improve exist.

• Some image elements do not have [alt] attributes.
• Some of the elements do not have a title. Some screen reader users may face challenges.
• Some links do not carry discernible names. This could impact the navigation experience for some screen reader users.
• Disabling zooming is problematic for users with low vision who rely on screen magnification to properly see the contents of a web page
• In certain places, the background and foreground colours do not have a sufficient contrast ratio. This may make it difficult for some users to read.
• All focusable elements do not have a unique `id`. This may make it not visible to assistive technologies.
• At places, heading elements are not in a sequentially descending order. This could impact the navigation experience for some screen reader users.

We are already in the process of transitioning our Website hosting from Strikingly to WordPress and should go live in mid 2024.

2. Our web and mobile apps:

We have put in place a phase-wise plan to address the following during the two year period 2023-2024.

Accessibility Problems for Users with hearing challenges

• Audio Control - Individuals who use screen reading technologies can hear the screen reader without other sounds playing.

Accessibility Problems for Users with a visual impairment, blind and colour blind

• Inadequate feedback (Controls, forms, and functionality): Nothing identifying to the user that an action had an effect. e.g. clicking on something and nothing informs the users of what has changed.
• Use other elements in addition to colours to communicate feedback: vibrations, and text to show every right and wrong action taken by the user within the application. To work on Guideline 3.3.1 error identification.

If you discover an issue or concern related to the accessibility of Wysa website or our apps, please contact us at [email protected]

We welcome your feedback and will try to respond within two (2) business days.

This statement is current as of Jan 11, 2024.