What is accessibility? If most people are using digital products, how can they be difficult to navigate? These questions may seem simple, but the answers are not. Apple's new liquid glass UI update serves as a good example here. It looks nice and clean, but in many areas, the text is unreadable due to the excessive blur effect used. This is surprising because Apple is known for its good design. Their accessibility guidelines are referenced by designers all over the world, but even they gave accessibility a back seat for this one.
Many designers still believe that accessible features and products are only for people with disabilities. Design teams often forget to consider this perspective when they begin the process of researching and designing their products. However, they need to think about all users when they start designing; that's when the products can be truly inclusive.
Learning Through ClientHeard
The first time I learned the importance of designing with accessibility was when I was working on the ClientHeard web app. It was a team project during my master's in Human-Computer Interaction at University College Dublin. Since it was our graduate project, I worked with three classmates to design a solution that helped clinicians communicate with their clients.
This project was in collaboration with St. Michael's House, an organisation that provides services to people with intellectual disabilities. The clinicians we interviewed specialised in dealing with individuals with intellectual disabilities.
Before designing the prototype, we spoke with five clinicians and conducted long, unstructured interviews. Through the interviews, we found that the digital devices the clinicians were currently using were quite complicated and difficult to use. The clinicians also had trouble communicating with people who spoke different languages than they did, and having a translator in the room raised huge privacy concerns.
Here's a simple explanation of how the ClientHeard app works. Clinicians use the main app, and clients use a remote. When a question shows up on the screen, the client can respond right away using the remote. This helps make communication easier for both sides.
You can also check out the full case study here.
The image illustrates a communication process between a clinician and a client who do not speak the same language. It begins with the clinician setting up a tablet using a platform called ClientHeard before the session starts. The client is given a remote control with large buttons that include symbols like a checkmark, an X, a question mark, and a speaker icon.
During the session, the clinician and client sit facing each other. The clinician sends simple yes-or-no questions to the client's remote through the tablet. The client presses the speaker button to hear the question spoken aloud in their native language through the remote's built-in speaker. They then respond by pressing one of the symbols — for example, the X button to say “no.”
The client's responses are saved in the system. When the session ends and the system is reconnected to the internet, the clinician can access the saved answers and write notes based on the client's input.
Real Feedback, Real Challenges
After finishing my degree, I didn't want the project to be buried and forgotten. I wanted to test the app and continue building on it. I had a basic prototype and a simple remote design, but no way to create a real device. So, I used a large tablet to display the remote on that screen.
I asked five clinicians to test the app and complete a session using it. I assigned them tasks such as editing and adding questions before a session and then asking those questions through the app. The patients were on the other side of the table, and they were given a tablet with the remote as the screen display. The clinicians sent the questions via the app, and I played the questions through a speaker while the clinicians responded using the tablet remote.
A clinician is seated at a table using a laptop with the ClientHeard interface visible. Across the table, a person (with their face covered by a smiley emoji for privacy) holds a physical prototype of a remote with large, colorful buttons.
Another clinician is seated across from a person who is holding the same prototype remote device with large buttons. The clinician appears to be observing or engaging in the session.
The whole process took 55 to 60 minutes for each session. After each session, I spoke with the clinicians to gather their feedback. From these discussions, I found that they all had quite similar issues. They mentioned that there were too many steps required to perform a few tasks on the app. Additionally, the app had usability issues and was not very easy to navigate.
Lessons from Accessibility Experts
While I was in the process of redesigning the app, I attended a design event hosted by Accessibility Ireland in April 2025. The event focused on the European Accessibility Act and its potential impact on digital products in the future. It truly inspired me to concentrate more on inclusive design in the app I was working on. I reached out to experts Michael Hanton and Anna Mészáros, who were kind enough to review my app and provide detailed feedback on how I could improve both the design and its usability.
Based on the advice and testing, I made several improvements to the design.
What I Changed
Screen 1:
A login screen with fields for "Email ID" and "Password," and a green "Login" button.
Feedback callouts:
- The page title is vague. It's suggested to use a clearer, more descriptive title like “Login to Client in ClientHeard” to improve clarity and screen reader compatibility.
- The contrast between text and background is too low, making it hard to read. It also notes that placeholder text (used in the form fields) disappears when clicked and shouldn't be relied on as labels because it's not accessible.
Screen 2:
A home screen that greets the user with “Hi, Anna” followed by the question, “What do you want to do today?” Two buttons are shown: "Care Meeting" and "Edit Question Bank." There are also navigation items in the top bar labeled "HELP", "LANGUAGE", and "SETTINGS".
Feedback callouts:
- All-caps text like "HELP" and "LANGUAGE" is more difficult to read, especially for users with learning disabilities, and may confuse screen readers. For example, "US" might be interpreted as "United States" rather than "us."
- The two buttons on the page lead to separate workflows. Clinicians requested an easier way to switch between them without returning to the home screen.
Screen 3:
A screen with a white pop-up box that asks “Ready to connect to the client remote?” with two buttons: “Connect to Remote” and “Manual Entry.” The navigation bar at the top again includes "HELP", "SPANISH", and "TOPIC".
Feedback callouts:
- The same comment about the two buttons applies here. Clinicians want the ability to switch between workflows without navigating back to the main screen.
Screen 4:
A welcome screen displaying "Hi, Anna" and a prompt asking, "What do you want to do today?" Below are two buttons: "Care Meeting" and "Edit Question Bank." The top navigation bar includes "HELP," "LANGUAGE," and "SETTINGS."
Feedback callouts:
- The greeting is friendly but lacks context. A more descriptive prompt could enhance user understanding.
- The all-caps text in the navigation items may hinder readability, particularly for users with learning disabilities, and could be misinterpreted by screen readers.
Screen 5:
A response card indicating "Jose is responding," featuring a clear layout and consistent visual design. Below this, there are updates about "Bluetooth" and suggestions for simplifying interface elements.
Feedback callouts:
- The title of the response card could be more specific to improve user comprehension.
- The updates regarding "Bluetooth" and other features should be restructured to minimize visual clutter and enhance accessibility.
Screen 6:
An activities overview screen displays a list of daily living tasks. A pop-up box prompts, "Ready to connect to the client remote?" with options for "Connect to Remote" and "Manual Entry."
Feedback callouts:
- The pop-up's wording could be clearer to guide users effectively.
- Similar to previous feedback, the buttons should allow for easier transitions between options without requiring users to navigate back to the main screen.
Even though the text and UI components appeared clearly visible to me, I was surprised to find they did not pass all contrast checks, even with seemingly dark colours. This shows how visual assumptions can be misleading without proper WCAG testing.
The image focuses on issues related to color contrast and accessibility.
On the left, there is a text input field labeled "Enter your organization email," where a red circle highlights the low contrast between the light gray placeholder text and the white background. This makes the text difficult to read, particularly for users with visual impairments.
In the middle section, a tool called "Colour Contrast Analyser (CCA)" is used to evaluate the contrast between foreground and background colors. The foreground color #9FAAB4 (light blue-gray) and background color #F1F6F9 (light gray) have a contrast ratio of 2.2:1. This fails the Web Content Accessibility Guidelines (WCAG 2.1) for minimum and enhanced contrast levels, meaning the colors are not sufficiently distinguishable for regular text, large text, or non-text UI elements.
The right section shows a similar scenario with the foreground color #E5EBF1 (very light gray-blue) against a white background. The contrast ratio is even lower, at 1.2:1, resulting in a complete failure of all WCAG 2.1 contrast standards.
In the earlier design, we only used colors (like green, yellow, and red) to indicate information or button states. This made it difficult for people with vision problems or colour blindness to understand which text or label on the screen was clickable and what it was trying to convey.
In the new design, I added text labels, icons, and clear borders so that everyone can easily see what each button or option means, even without relying on colour.
The image illustrates improvements in user interface design, focusing on button clarity and topic selection. On the left, a "Before and After" comparison shows buttons with icons and labels for different responses: "Yes," "Not Sure," and "No." In the "Before" design, the buttons have inconsistent spacing, smaller icons, and less clear labels, making them harder to interact with. The "After" design addresses these issues by enlarging the icons, using clearer labels, and maintaining consistent spacing and layout. The improved buttons are more accessible and visually appealing, ensuring better usability for all users.
On the right side of the second image, another "Before and After" comparison addresses topic selection. In the "Before" design, the topics are listed as plain text, such as "Activities of daily living," "Family," "Health," and "Housing." This design lacks visual differentiation and makes navigation less intuitive. The "After" design adds icons to each topic, such as a house for "Daily Life," a family icon for "Family," and a tree for "Outdoors." The new design also uses larger clickable areas and better spacing, making it more user-friendly and accessible, particularly for individuals with cognitive or visual impairments.
Redesigned prototype
Here are a few screens from the redesigned prototype.
The image above shows six final screens from the redesigned ClientHeard web app. The interface includes a simple login screen, a category selection page with clear icons and labels, and a client list view that displays details like name, age, language, and device status. Other screens show how clinicians can select, manage, and reuse prewritten questions or add new ones. Each section of the app uses high-contrast colours, clear typography, and large clickable elements to ensure ease of use for a wide range of users.
Accessibility was a key focus in this redesign. The app avoids relying on colour alone by pairing icons with text, uses consistent layouts for cognitive clarity, and ensures all buttons and forms are clearly labeled for screen readers. With improvements in contrast, navigability, and overall usability.
Accessibility considerations:
- Icons + text labels to reduce reliance on colour.
- High contrast for better readability.
- Consistent layout to support cognitive ease.
- Large clickable buttons for motor accessibility.
- Keyboard navigability and clear focus states.
- All UI components have accessible labels for screen readers.
Another round of testing
Once I had the redesigned prototype ready, I tested it again with seven clinicians to see how well it worked. This time, they were able to move through the app and finish their tasks about 50% faster. It was encouraging to see that the changes really helped.
Even though the app is still a work in progress and there are many other accessibility features I still need to improve, this has already been a valuable learning experience. It helped me understand how thoughtful design can make a real difference, and it showed me that accessibility should always be part of the process, not something added at the end.
What I learned
Here are a few things I learned along the way:
- Don't rely only on colour to show meaning. Use labels, icons, or shapes to help explain things.
- Make sure contrast is strong enough so that text is easy to read. Follow WCAG guidelines.
- Plan and stick to an accessible colour palette to keep the design clear and consistent.
- Think about how users will interact with the app, including with a keyboard. All buttons and forms should have clear states.
- Keep links and buttons easy to see and tap. Avoid small or confusing buttons.
- Add notes to your mockups to explain how different parts of the app should behave, especially for accessibility.
Now that the European Accessibility Act is in place, we may start to see a shift in how organisations think about designing for accessibility. In the future, I hope that India will eventually follow the same path. Currently, there is a lack of compliance and awareness: Budget constraints often lead to accessibility being dismissed as 'too expensive,' despite the extensive effort required. Furthermore, many treat accessibility as a mere checkbox exercise rather than a true commitment to inclusivity.
At the very least, we can hope that more teams will embrace the importance of inclusive design, understanding that accessibility is not just a legal requirement but a moral imperative.
About the author
Hi, I'm Erum Gour. A designer and barista with a love for both design and latte art. I have been living in Ireland for two years and specialise in User Experience Design, including UI and graphic design. I believe in creating accessible designs for everyone.
Before becoming a full time designer, I worked as a journalist, illustrator, and comics artist, which allows me to infuse creativity and empathy into my projects.
Get involved!
We invite you to explore, learn, and engage with us. Join our email list to stay updated on the latest news, events, and resources. We also welcome anyone who wishes to collaborate with us to reach out to us.
Let's build a digital world where accessibility isn't just a feature but a fundamental right.
Stay tuned for updates, and let's make the digital landscape accessible for all.
Join our email list
If you would like to be kept up to date about Accessibility Ireland feel free to sign up to our email list.