A11y for The Weather Channel
This was a school project for inclusive design. We worked as a group of four students with users who were blind. After school is done, I added the final redesigned UIs with my own time.
Our group chose to study the accessibility of The Weather Channel app (Weather Channel) given that: (1) checking weather is one of the most common tasks people carry out every day; (2) users who are blind may not fully leverage heavy icons and radar maps.
As a group, we collectively defined our testing goal:
HMW improves the accessibility of the Weather Channel app for users who are blind?
Project Roles
UX Researcher (participant recruiting, and testing) — Group;
UX Writer and Presenter (technical report-outs) — Group;
UX Designer — Personal.
Tools Used — Testing + Design
Google Docs, Sheets, Drive; MS Word, Excel;
Rainbow Spectrum — Robust; Phone Recorder;
Adobe XD — Voice Prototype.
Process Overview
Problem refining with literature and competitor research → Usability Testing → Redesign
Project Background
We were working with users who were legally blind (little perception of light and shape, medical definition link) and mainly used canes and guide dogs for navigating around the city. The median age of the four testing participants was around 51. All of them used VoiceOver (iOS built-in screen reader) on the iPhone for this project. There are guidelines like WCAG 2.1, ARIA (Accessible Rich Internet Applications), which would help to make websites and mobile applications accessible, i.e. readable by screen readers like VoiceOver.
When testing for accessibility, many design changes can be audio and need to be implemented via HTML/CSS rather than just the UI changes. To provide a better understanding, I made a voice-interactive prototype to demonstrate how the change would be like.
Step Details
- Problem Refining
Testing is a way to pin-point UX opportunities and solve for better. However, good testing will start with a good problem/goal definition. We already knew that we were looking into the domain of accessibility, but specific goals would help us gain more practical insights. Since we were a new team working on a new project for Weather Channel, we decided to look into the existing literature on common challenges users faced.
After reading fifteen academic articles, we identified the following main challenges:
⚠️ (1) heavy usage of icon and images are hard for screen readers;
⚠️ (2) long tabbing structure that hinders efficient navigation with screen readers;
⚠️ (3) not enough information on the uncertainty of the forecast.
We also identified competitive features from popular weather apps among blind users:
👉 (1) real-time weather alerts;
👉 (2) all-in-one weather info:
👉 (3) integration with Siri.
We also set the following guiding questions for testing so we can better understand observations during testing:
👉 (1) how are users interacting with Weather Channel now?
👉 (2) what are the key pain-points for users who are blind?
👉 (3) how easy/difficult it is for users to use Weather Channel?
👉 (4) what are some practical insights we can apply to the redesign?
2. Usability Testing
We decided to recruit four participants for this round of testing given. We allowed participants to name three top tasks they perform on a daily basis. Then we asked each user to perform the tasks on a weather app of their choice, and Weather Channel.
Given that our participants were blind, we offered to schedule the testing sessions in their homes. We had three participants ended up meeting with us in their houses and one in DePaul’s loop library.
All four participants ended up choosing iOS Weather as a comparison, and we consolidated all tasks named into five common ones:
👉 (1) checking the weather for another city;
👉 (2) checking local hourly forecast;
👉 (3) checking current/real-time temperature;
👉 (4) checking sunrise/set time;
👉 (5) checking the local weekly forecasts.
We found that when switching to Weather Channel:
⚠️ (1) checking the weather for another city was much more difficult;
⚠️ (2) local hourly forecast info was long and hard to listen to;
⚠️ (3) many icons had improper or no alt-text;
⚠️ (4) pop-up windows and ads were not labeled;
⚠️ (5) limited resources on how to integrate with Siri.
We further grouped the above findings into three designable insights:
✔️ (1) fixing alt-text and element labeling in HTML/ARIA;
✔️ (2) fixing tab order (need to talk to Dev);
✔️ (3) adding tutorials on how to use Siri/Voice interactions.
Page to Page Breakdown
Image to the left: landing page of Weather Channel. The circled “Chicago, IL” is where users click to edit their location/city. However, VoiceOver read it as “GPS Location”, 3 out of 4 users did not even realize this element was editable.
In the mid-session of the page, the hourly weather was read by VoiceOver as “3p, 4p, 5p, 6p, 7p…4 degrees, 4 degrees, 4 degrees, 3 degrees, 3 degrees”. This was a tab order issue where the information should be regrouped as “3p/ 4 degrees, 4p/ 4 degrees…”
on the bottom center, the circled icon triggered an action to take the users back to the home page. However, the icon was missing alt-text, and VoiceOver can only say “possible text: the weather channel”. Actionable items should be labeled to say what action they do as well, which is missing here.
Page to Page Breakdown Cont.
image to the left: the circled icon with the sun was read by VoiceOver as “sun, possible face, and medicine”, which is inaccurate.
The greyed box on the bottom of the page was actually an advertisement, however, there were no aria labels on the area/div (HTML syntax). VoiceOver either read the detectable text literally (e.g. “find the perfect gift”) or just make a “beep” noise, which caused confusion to users since most of these lines are irrelevant to weather information and “out of context.”
3. Redesign — Personal Work
I speculate a VoiceOver/ARIA update would be implemented by the Dev team directly (probably more efficient in certain cases). However, for the benefit of demonstrating changes, I made the following voice-interactive prototype to demonstrate the potential of our design changes. The link is in the caption (please click on the page to listen to VoiceOver simulation, and use the right arrow key on your keyboard to navigate to pages).
Testing the Design
To evaluate, I tested the design with someone blindfolded.
Here is the list of tasks I asked the user to perform:
👉 1. find where to change the city
👉 2. add a city to his favorite
👉 3. check hourly weather
👉 4. general browsing and switching tabs in-app
I found that:
👉 1. label updates for change and favorite a city was successful. the user finished easily and gave a rating of 4 and 5 (easy, and very easy).
⚠️ 2. abbreviations in labels may cause confusion. when checking hourly weather, the users rated a 2 (difficult) because it was reading “2 p” rather than “2 pm”. When encountered an ad, the label “ad” vs. “advertisement” read fast and the user cannot understand. Hence, this task was also rated a 2 (difficult).
👉3. label updated on the bottom navigation was successful, as the user commented: “This is pretty straightforward.”
For iterations:
✔️ So we need to spell out all abbreviations in the ARIA labels and alt-text
Limitations
- Redesign evaluation:
I only tested the redesign with one user, who is also a sighted person that was blindfolded for the testing. Ideally, we would want more data and users who are blind.
- User group:
We only tested with users who were new to The Weather Channel. However, this might be less representative if we want to cover all user groups.
End Notes
All in all, one of the biggest things I’ve learned in this project is working with users with disabilities. Get to interact with them in-person was very valuable in terms of demystifying “living with a disability.”
Spending extra time building the voice prototype also helped me level up my skills using Adobe XD.
