I have albinism and low vision, and I research accessibility for people with low vision. I use screen magnification and high contrast, and I sit close to my screens. Finding useful tools and ways to use them has often depended on my own trial and error.

Marvel’s Wolverine brought this to mind. The game came out on September 15, with a glowing scent trail that guides players through parts of the story. Some players have called the guidance “hand-holding,” and critic Gene Park nicknamed the trail “fart gas” (Kotaku). I understand why someone who wants to find their own way would want to turn it off. I also think it matters that players encounter useful help before they know to ask for it.

Trying a feature before deciding

A lot of accessibility depends on awareness of what tools are available. I can’t choose a feature I don’t know exists. I also might not know whether it helps me from its name in a settings menu. Sometimes I have to try it first.

When a feature starts on, I can see or hear what it does while I use the game. I can keep it, adjust it, or turn it off. Someone who has never considered that kind of help gets the same chance to learn about it. That opportunity to try a feature is why I favor having suitable assist features on by default.

When a feature starts off, a player has to find the setting, understand its description, and try it without knowing whether it will help. That asks a lot of someone who may already be struggling to see or navigate the interface. A setup menu can help, but it still depends on players recognizing what they need from a list of options.

I know that a default someone doesn’t want also creates work. They have to stop, find the setting, and switch it off. For example, a player who finds a guiding line distracting first has to know what the game calls it, and then find it in a long list of options. Usually, I think that is less work than searching through unfamiliar options for a feature you might need. But I don’t want to assume that turning it off is always easy. If the setting is hard to find, that can be frustrating too.

So I want games and apps to make settings easier to search and understand. A player should be able to find a feature after first trying it, and then choose whether to keep it. That matters for both the person who needs the help and the person who doesn’t want it. This is why I think it’s important to make settings easy to find and try, which I discuss in Making settings easier to find and try.

How I have found help for myself

For me, and for people I know, useful tools can go undiscovered. You may keep doing something the hard way because you don’t know a tool exists, or because you don’t know another way to use one you already have. Finding out can depend on trial and error and on knowing where to ask for help. That takes effort that the design rarely acknowledges.

I’ve used text-to-speech services for many years. But only after buying a new mouse and playing around with Balabolka, a free text-to-speech program, did I discover that I could combine the two. I can use the extra buttons on my mouse to have selected text read out loud right away. That has been a game changer for me. I get support on demand, when I want and need it. A screen reader, in comparison, is cumbersome and difficult to use, and it reads out much more content than I want. In the end, I do want to use my residual vision as much as I can. It took a new mouse and some trial and error for me to find this way of reading.

Sometimes the tools we need don’t exist, or they are very hard to find. Then people have to create their own DIY solutions. For example, I recently built SlideNotes, a small web tool that lets me view and comment on slides. I find doing that in Google Slides or Figma very inaccessible with low vision. I made something that works for me and shared it in case it helps others.

AI makes it easier to build small DIY tools like this. But building one can still require a subscription, as well as the knowledge and experience to use AI for the job. I don’t think people should have to build their own solution just to discover a useful way to work. In a game, a helpful default can introduce an option to people who would never have searched for it.

Where Wolverine gives players a choice

Wolverine shows why the option to turn something off matters. The story scent trail starts on, but as of September 26 it still can’t be turned off. That is a reasonable reason to complain, especially if you want to explore without that guidance. I support the default being on, but I also want an off switch.

After players criticized the trail, Insomniac reduced its opacity for everyone. Can I Play That? argued that a less visible trail could be harder for low-vision players to use. A later update added off switches for three collectible aids, while story-critical Senses still appear. I would have preferred a choice for the story trail too, along with control over its intensity. That would let players who want the visual guidance keep it visible and let others reduce or turn it off.

I don’t know whether the story trail is an accessibility feature in the strict sense. Insomniac hasn’t called it one, and I haven’t seen anything that measures how low-vision players use it. The concern about visibility still deserves attention. A visual guide can help some players even if the game did not label it as an accessibility option.

The game has a clearer example of my argument. Its screen reader starts on and asks at first boot whether to keep it. A player can turn it off with one button. Subtitles are also on by default, according to SightlessKombat’s review. It makes sense to me that the menus start out speaking, so nobody has to navigate a silent menu just to find the screen reader.

The same reviewer said the game doesn’t explain how to use Navigation Assist, which starts off. That is the discovery problem I worry about. The game offers help, but a player first has to be motivated to seek it out. Only then can they learn that it exists, find it, and figure out how it works. If you don’t know a feature exists, it is hard to be motivated to look for it.

Wolverine also offers a High Contrast mode with choices for character and object colors, outlines, and the background. Players have to turn it on themselves. It gives players ways to adjust the visuals. I would like the story trail to offer similar control.

Making settings easier to find and try

I would start suitable accessibility and assist features on when players can easily turn them off. I would also make accessibility settings visible from the very beginning. For example, a setup menu when the game first starts could go through the accessibility features, give examples of what each one can help with, and let players choose what to keep. After that, I would keep the controls easy to find, including a way to search settings. Call of Duty: Modern Warfare III, for example, tags settings for motor, vision, audio, or cognitive adjustments. Players can filter by those tags (Call of Duty). For visual guidance, I would also offer intensity and color choices where they make sense. Different players may need different levels of visibility, so I wouldn’t reduce the trail to one intensity for everyone. We found this in our work on VeasyGuide (Sechayk et al., 2025), where low-vision learners personalized the visual guidance in presentation videos. People chose different colors, shapes, and thickness, because what worked for one person didn’t work for another.

Wolverine’s first-boot presets can introduce features, but a category such as “Vision” still asks players to recognize a need in advance. I would also show what an option does while someone chooses it. This is sometimes called WYSIWYG, “what you see is what you get.” Forza Horizon 6 shows a live preview of most settings in the game world as you change them. Marvel’s Spider-Man on PC applies graphics changes instantly behind the pause menu (Digital Foundry). I would like the same approach for accessibility settings. If I can see what High Contrast or larger subtitles do while I’m choosing them, I don’t have to guess from their names.

Showing how people use settings

I’d like settings to explain more than what an option does technically. A short note could describe how low-vision testers experienced a High Contrast mode, how blind testers experienced audio cues, or how Deaf and hard-of-hearing testers experienced captions. These would be examples of what an option can do for someone, rather than promises that it will work the same way for every player.

A lot of accessibility strategies spread by word of mouth. Hearing about someone else’s experience is often what makes you think, “Maybe I have a similar need,” or “That could be really helpful for me.” To make that possible in a game, developers would need to include disabled people in testing and put their experiences next to the relevant settings, where players can find them.

Finding help without going through every option

Having many settings can be good for accessibility because players can fine-tune the game. But a long list can also be overwhelming when you don’t know what you need. Wolverine advertises over 100 accessibility features (PlayStation Blog). Going through a long list of options one by one can lead to decision paralysis, especially if you’re not sure what you need in the first place. So I think there should be a balance between the number of settings and the accessibility they actually provide.

An AI assistant could offer another way to reach the settings. As a low-vision player, I could say, “I can’t tell which objects I can interact with,” or “I’m not sure which way I should go.” The assistant could surface the relevant settings and change them for me. I could try the result while playing, then keep it or change it back.

I want more people to encounter these tools, including people who have never thought of looking for them. Some will turn them off. Others may find something useful that they would not have found in a menu. Making features easy to try, adjust, and turn off would give both groups a useful choice.

Then, a few seconds later, a second thought showed up:

Wait… what happens after somebody applies it?

For some context, I have albinism and low-vision, and I research accessibility for people with low vision. I also file accessibility bugs and contributions, and I have watched some of them sit quietly in a backlog. Nobody argued with me. Nobody closed the issue either. It simply stopped moving.

So I’m genuinely happy GitHub made this change. I’m also very interested in the process waiting on the other side of the label.

The label makes accessibility visible. Visibility is not the same as priority.

Why the label is genuinely useful

GitHub has always let projects create custom labels. Some repositories already used accessibility or a11y. Others relied on words in the issue title, or filed the barrier as a bug, an enhancement, or whatever else felt close enough. What was missing was a shared default that tells every new project: this is a category of software problem you should expect to run into.

That gap is measurable. (Bi et al., 2021) searched 1,000 popular GitHub projects for accessibility-related issue text and tags, manually checked the results, and collected 11,820 relevant issues. Developers were discussing accessibility. Those discussions just weren’t represented consistently across projects. A default label gives that work a common name.

A common name makes barriers easier to filter, route, and count. It can connect an issue with somebody who actually has the relevant accessibility knowledge. Because it’s a default, it shows up in projects that would never have created it themselves. This has a secondary effect of raising awareness to the importance of accessibility.

Defaults can shape how people construct workflows. For instance, GitHub’s good first issue label, now populates a repository’s contribute page. (Tan et al., 2020) found that projects increasingly adopted the label over the preceding decade, although many labeled issues still did not lead to a newcomer contribution. The label didn’t guarantee an outcome, but it changed which work became visible to newcomers.

The new accessibility label can do the same thing for accessibility work.

So, what’s the risk?

A label is a routing mechanism, and routing can lead to very different places.

Imagine a project with no accessibility owner, no shared severity rules, and no release criterion for accessibility barriers. Before the new default, an accessibility issue might have landed in the general bug queue. Now the team can separate it immediately. The issue gets easier to find, and it also gets easier to leave in a dedicated queue that just gets forgotten, since nothing else depends on it.

A dedicated queue that nobody owns is not a workflow, it’s a waiting room.

Forgotten accessibility issues only require a process where accessibility is visible but disconnected from the ordinary decisions about severity, ownership, and releases.

That environment is common. (Alshayban et al., 2020) found that many developers lacked awareness of accessibility principles and of the tools available to check them. (Bi et al., 2022) similarly found that accessibility was often treated as a separate concern instead of a first-class consideration throughout development.

In that environment, a label can organize the work without giving anybody a reason to act on it.

“Later” is not a schedule

Postponing accessibility isn’t a neutral scheduling choice.

The W3C’s business case for digital accessibility recommends integrating accessibility from the beginning, because retrofitting an inaccessible product later is generally harder and more expensive. The reason is structural. A missing alt attribute can be a small, local change. A custom component built without semantics or focus management may need a redesign. And if navigation, dialogs, and forms already depend on that component, the team also has to inspect and update every place where it’s used.

And this work moves downstream easily. (Indika et al., 2026) surveyed 110 mobile developers across 43 countries. Most of them considered accessibility important, yet accessibility testing typically happened late in development. The study also identified technical and organizational constraints that made implementation difficult.

That’s the gap that worries me.

Accessibility debt compounds like technical debt, except somebody is locked out while the interest accumulates.

What turns a label into a commitment?

The label is useful infrastructure, but the workflow around it decides what it means. Here are five things I would want in any repository that adopts it:

1. Give the label an owner and a response target. Name who triages these issues and how quickly the first review should happen.
2. Use accessibility alongside severity, not instead of it. A barrier should carry accessibility and the same priority vocabulary as any other bug. The label describes the type of problem, not its importance.
3. Add it to existing repositories. The default only applies to new repositories. Older projects can add the label in their settings, and they’re often the projects with the deepest accessibility debt.
4. Move accessibility upstream. A label only sees barriers somebody already found. Pair it with accessible design requirements, a definition of done, pull-request guidance, and appropriate automated and manual checks.
5. Measure the workflow, not only the backlog. Track time to triage, ownership, severity, and resolution. GitHub reports that an internal, AI-assisted accessibility-feedback workflow reduced resolution time by 62%, with 89% of issues closing within 90 days. Those results didn’t come from a label alone. They came from combining structured metadata with automation, accountability, and measurement.

The label is a great addition, but it should not be an excuse to defer accessibility problems to “some other time”.

The label is how we start

GitHub did something accessibility advocates have wanted platforms to do for years. It recognized accessibility barriers as a normal category of software work and put that category in front of every new project.

Now thousands of repositories have to decide what the category means in practice.

A label can make accessibility work visible, but incorporating it into a workflow is what makes accessibility happen.

References

I have albinism and low-vision. This is also the lens through which I do my research, as a motivator for the tools I build, and as a reality I navigate every single day. I use screen magnification, high contrast settings, and a carefully positioned monitor. I sit close to screens.

I always make adjustments to my environment, to make working easier. But, don’t we all?

For many years, the world has described my situation using this phrase: special needs. As if what I need is somehow rare, exotic, or beyond the reasonable scope of what the world should offer.

It is not.

Let me tell you what I need. I need to read a research paper without figures being bitmap images; which, when I magnify turns into a blurry mess. I need to watch a video lecture where the instructor uses a thick pen when marking on the slides. I need a website that does not break when I zoom to 200%. I need a game that does not require me to read text at 8pt against a gray background. I need a movie streaming service that let’s me change the visuals of the captions freely so I could read them (no matter how tired my eyes are).

Why on Netflix, I have to choose between 100% and 200% font size for captions? Why can’t I choose 150%? I don’t understand why the size adjustments are so limited.

Are any of these special? Are they unusual? Are they extraordinary requests that go above and beyond what the average person expects from the world?

No. They are basic. They are fundamental. They are the same access to information, entertainment, and education that sighted people take for granted every single day.

The word “special” implies something extra. Something above the baseline. When we call my needs “special,” we are saying, implicitly, that my baseline is already satisfied, and that I am asking for a bonus on top of it. But that is not what is happening. What is happening is that the baseline was built for someone else, and I am asking to be included in it.

I understand why the term exists. It came from a good place. People wanted to signal that disabled individuals have needs that differ from the norm, and they wanted to communicate that those needs deserve attention. “Special” was meant to be a kind word. Respectful. Acknowledging.

But good intentions do not neutralize bad framing.

When we call a need “special,” we shift the responsibility. The implication becomes: there is a normal world, and then there are people who need special accommodations to function in it. The world is fine. These people just need some extra help.

But what if the world is the problem?

What if the issue is not that I have special needs, but that the world was designed without me in mind? What if the problem is universities building lecture halls without thinking about the distance between the seats and the board/screen? Software companies shipping products without making it navigable with a screen reader? Office buildings being constructed with windows for walls, because it’s more fashionable? Bus stops being built with information signage that is out of reach for low-vision people?

That is not my need being special. That is the world being exclusionary.

In primary school, I had to leave class to enlarge my own handouts on the copier (no, the teachers wouldn’t wait for me to return before continuing class). They also kept forgetting to write large on the board (even after I asked them to do so 5 minutes earlier). And most annoyingly, my school refused to install curtains because they “don’t have the resources”, so my family had to purchase and instal them and uninstal them and reinstal them every year as I moved to a new classroom. Every single year.

None of that is because I had special needs. It is because I was an afterthought. That is not a personal failing on my part. That is a systemic failure.

This distinction matters because language shapes policy. When we frame disability as a matter of “special needs,” institutions respond by building special accommodations as optional add-ons. Accessibility becomes a checkbox. A budget line item. A request you have to submit in advance, in writing, with justification.

When we reframe disability as a fundamental design failure, the response changes. Accessibility becomes a design requirement. A baseline. Something you build in from the start, not something you bolt on after the fact.

See how I redesigned the new Google Icons to be more accessible. Is this a “special design?” No, it’s just another options for a design that would fundamentally be easier to see for more people.

One framing says: this person is different, so we should make an exception for them.

The other framing says: this person was excluded by design, so we need to fix the design.

These are not the same thing. The first creates charity. The second creates equity. I want the system fixed.

I am a researcher. I build tools. I run studies. I talk to users about how they actually experience digital content. And over and over again, I hear the same story: a person with a basic, reasonable, predictable need, trying to do an ordinary thing, hitting a wall that should not exist.

When I study how low vision users look at data visualizations (Sechayk et al., 2026), they are not asking for extra features. They just want to read a chart. But because standard charts are not built for magnification, users lose the axis label the moment they zoom in on a data point. We built tools to bring that context to the cursor. The need was not special; charts are just not designed with low-vision users in mind.

The same goes for educational videos. Low vision learners do not need a different curriculum; they just need to know what an instructor is pointing at (Sechayk et al., 2025). We built a tool to dynamically highlight those subtle visual cues. It helped low vision users immediately, but strikingly, it made sighted students more engaged too. Good design is just good design.

Or look at the web. Modern sites force screen reader users to spend minutes navigating irrelevant elements to do what takes a sighted user seconds (Mohanbabu et al., 2025). We built a system that uses AI to filter out that structural noise. We did not build a special internet. We just fixed the navigation.

These systemic failures go beyond vision. Looking at the email history of a professional with chronic illness and ADHD (Pimenova et al., 2025), the pattern is the same: standard tools operate as invisible barriers, and working around them is exhausting, invisible labor that gets miscategorized as a personal coping strategy rather than evidence of design failure.

These are not special accommodations. They are fundamental and basic needs.

So what should we call it instead? Just “needs” works.

Words matter. The words we use to describe a problem determine what solutions we build. If we think people have special needs, we build special programs. If we think people have unmet needs in a world that excluded them, we build a better world.

I still see papers that use that terminology. And I always cringe when I do. Even papers from recent years still use “special needs.” I know that language is not easy to change. But every small step we take, takes us a little bit closer to the top of the hill. So, we better get going.

I do not have special needs. I have needs. They are basic, and they are often forgotten or ignored. Let us start there.

Is this Docs or something else? I have to lean in and check the label… Oh It’s actually Calendar. Wow, this is confusing.

This was my genuine first impression when Google surprised me by changing it’s icons (again).

I am an active user of Google products. I spend (too many) hours on YouTube, manage my workspace on Drive, write and collaborate with Docs, Sheets, Slides, manage my meetings with Calendar, and even use Meet every once in a while. But that random day, I was very confused.

It took me so long to get used to these multi-colored icons… and now, after I was finally recognizing things a bit easier, they change it again? I’m back to square one.

That’s what I thought to myself.

For some context, I have low-vision, which means that my eyesight is pretty bad (yes, even with glasses it’s still bad). This never stopped me from doing anything, though! I traveled the world, got my bachelor’s in Computer Science and Film, and now a PhD candidate, researching on accessibility in the area of human computer interaction (HCI). However, having vision problems does mean that some things are just very difficult. So, when Google changes it’s icon design, I can no longer easily recognize at a glance if what I am about to tap on is what I was intending to.

Whenever I open my phone, for example, and look for the Calendar, I need to dedicate additional cognitive effort to making sure I am not mistakenly tapping Docs. This is not only about effort, it also makes these small actions, which should be seamless, take significantly longer for me, impacting my stream of thought, focus, and overall productivity.

The new icons use subtle gradients and a uniform design, which is aligned with other apps like Gemini. And some sources say that this change is meant to reflect the presence and availability of AI in all apps. But that’s not all. Google is also addressing one major criticism that many had (including myself) with the previous icons, which were mandated to include all four company colors:

They all look so much alike, it’s so hard to tell them apart!

Compared with the previous icons, the new icons use more distinctive colors throughout; however, is that enough to make them visually distinct even when places side by side? For me, it absolutely a step in the right direction, but definitely not enough.

And I’m not the only one. Online, several people echo the same sentiment that I have. Comments on videos and articles that discuss and showcase the new design express how confusing and lacking in accessibility the new designs are.

Source: BrenTech on YouTube

Source: BrenTech on YouTube

Source: 9to5Google on YouTube

The icons are WCAG 2.1 compliant, but that’s not enough

The Web Content Accessibility Guidelines (WCAG) are a set of guidelines to ensure the web remains accessible to diverse users. Google’s icons almost certainly satisfy WCAG 2.1. The key criterion for icons (1.4.11 on Non-Text Contrast) requires graphical objects to maintain a 3:1 contrast ratio against adjacent colors. For the most part the icons maintain this guideline, since the adjacent colors are “the background”. So, as long as the icons maintain a 3:1 contrast ratio with the background it’s all good right? Wrong. For low-vision people the ability to recognize via a glance is a very important aspect of accessibility.

The icons (mostly) maintain a good contrast with the background, but at a glance, some icons look very similar to other icons. For instance, the Calendar to the Docs, Chat with the Sheets, and Meet with the Slides. While the icons, in most cases, do include some text above or below, text is not easily recognized at a glance when your vision is unreliable. But this is not necessarily Google’s fault, the guidelines do not address issues of relational visual distinctiveness.

The WCAG does provide guidelines for web elements to be perceivable, by ensuring captions, alt-text, contrast, and safe magnification of content among others. However, the guidelines do not indicate how to make visual elements glanceable.

Glanceable

(of graphics) Understandable at a glance, or with occasional glances, and therefore requiring only minimal attention. Glanceability is the property of being glanceable.

Source: Wiktionary the free dictionary

To evaluate glanceability, we must also evaluate visual objects in relation to other visual objects around them. We can do such evaluation by using existing WCAG items and extend them with studies on visual perception (Treisman & Gelade, 1980). For instance, do they use a distinct color compared with nearby objects? Is their shape distinct? Are the colors they use balanced differently? As per WCAG (1.4.1 on Use of Color), color should not be the only distinguishing factor. For assessing glanceability, we must use other visual indications, such as contrast, shape (silhouette), as well as layout (distribution of colors).

For instance, we can have two icons use the same colors, but one would be square-shaped and the other triangular-shaped. Similarly, the colors could be spread differently between the icons, with one shifting from light to dark and the other dark to light. We could also use other visual embellishments, such as strokes or shadows, to make it easier to glance at objects. The singular goal is to make it easy to recognize a specific known visual object at a glance.

Visual perception and the effect on how we glance

Research in visual cognition shows that the brain processes basic visual features, such as color, shape, and orientation, rapidly and in parallel. When an icon differs from its neighbors along a single, clear feature, it pops out immediately and automatically. But when telling two icons apart requires combining multiple subtle features, a slightly different shade of blue, a slightly different gradient, a slightly different stroke, the visual system has to scan each one deliberately (Treisman & Gelade, 1980). That process is effortful for any person, but for low-vision people, processing these subtle differences quickly is a significant cognitive overload (Sechayk et al., 2025).

Hint: I flipped the placement of some of the icons for the added challenge.

This is not just theoretical. Studies on mobile app icon sets show that increasing color similarity between icons measurably degrades visual search efficiency and lowers perceived usability, even among sighted users (Trapp & Wienrich, 2018). Some icon pairs (like Calendar and Docs) do not just share colors; they share a color, shape, a gradient style, and similar layout proportions. Each of these individually might be a small difference. Together, they leave almost nothing to distinguish the two at a glance. While some differences exist, they are subtle, and mostly indistinguishable at a glance for low-vision people. This issue is most noticeable with the Meet x Slides, Calendar x Docs, and Chat x Sheets pairs.

What if low-vision people designed the icons?

What if a low-vision person had designed the icons to begin with? What would I had designed? Would the icons be more accessible then?

I decided to find out, and redesigned Calendar and Docs as a small exercise. Same blue gradient family, same glassmorphic aesthetic, but with a different visual structure.

For Calendar, I made the date number significantly larger, so it fills most of the icon rather than sitting as a small detail inside it, while still using a thinner stroke style. I increased the angle of the blue calendar page, and extended the presence of the light-blue portion on the top. Instead of an hourglass design, I used a single angled page style, similar to standing desk calendars. Finally, I increased the contrast between the gradient colors (dark turned darker, light became lighter).

For Docs, I increased the size that the folder corner is taking, and replaced the abstract interior with a thick three-line layout that creates more dominance of the white color on the overall layout. I also reversed the main color gradient so that the darker portion would contrast better with the three white lines. Finally, similar to the Calendar, I increased the contrast between the gradient colors.

I did not change the color profile. I changed what those colors were doing.

The result is what I’d call an internal anchor. The large thin-lined white number (vertical presence) and the thick text lines (horizontal presence) give a low-vision user something to aim for that survives degradation. There are multiple new ways to distinguish them apart from a glance, such as the shape, the presence of white, or the way the colors lean. The interior carries more information and the exterior contains more contrasting differences. While it does not entirely simulate the perception of low-vision people, the two icons break apart perceptually even when blurred.

Is this the perfect design? No. But it’s a design that is much easier for me to recognize at a glance, and that is the point. The icons are still visually cohesive with the rest of the Google icon family, but they also have more visual information that survives degradation. And, of course, it can even be better.

The tension between aesthetic consistency and accessibility is real. But my experience here suggests it’s surmountable. Not by abandoning Google’s visual language, but by being intentional about what visual information survives at a glance.

So, what can we do?

This isn’t about Google making a careless decision. It’s that the design process for these icons almost certainly didn’t include people with low vision in any meaningful way. A compliance review would have passed. An aesthetic review would have praised the cohesion. A standard usability study might not have surfaced the problem at all. The failure mode I’m describing is invisible to the tools most design teams routinely use, and that’s exactly what makes it worth naming.

How can we improve glanceability? Involve low-vision people in the design of icons and visual interface elements from the beginning.

Research shows that in many cases accessibility improvements positively impact everyone (Sechayk et al., 2025). For instance, multi-touch screens were originally developed as an assistive device. So hiring designers with low-vision, or consulting low-vision people throughout the design process can make icon design more usable and accessible overall! Low vision is a wide spectrum of diverse conditions, and no guideline fully captures that range. The people navigating these interfaces every day know where they break.

Google’s icons are beautiful. For many of us, they’re also confusing. Those two things shouldn’t be in conflict. Designing for glanceability across the full range of human vision isn’t a constraint on good design. It’s part of what good design means.

References

The month of February in Japan is special for many reasons. The Kawazu Zakura, the earliest of the cherry blossoms, are starting to open, the weather is slowly warming up, it’s the month of the Emperor’s birthday… and the plum trees are blossoming! Last weekend I went on a little Tokyo trip to see the plums. I visited a quiet little area I’ve never been to: Hanegi Park.

What can you see at local Japanese festivals? What kind of plum celebrations are there? And how accessible are festivals in Tokyo?

I’ll try to answer these questions in this post!

To get to Hanegi Park I first took the train to Umegaoka Station on the Odakyu Line. 🚆

Fun fact: the station name roughly translates to Plum Hill.

Thankfully Google Maps is very well integrated in Japan, and you can see a lot of details like which train car to board, as well as exact times and durations.

Tip: if the train is supposed to arrive at 2:21pm, do not board the 2:19pm train.

Station area market with Japanese kitchenware, chopsticks, and cultural items

Station area stall selling pickled Japanese plum

After arriving at the station, I was greeted by a few stands selling Japanese dishes, ornaments, and—in the spirit of the plum festival—limited-edition pickled sour plums. I love these on top of rice, so I had to get some! 😋

At and around the station (and in most big cities in Japan) there are yellow blocks to guide people. These are called Tenji Burokku (点字ブロック), which translates to “Braille Blocks.” They are primarily used to guide blind people and have different patterns that indicate paths and entrances. As a low-vision person, I sometimes use them as visible guides that will (probably) lead me to where I want to go.

I always say, “when in doubt, like Dorothy, follow the yellow brick road.”

Yellow braille blocks at a train platform in Japan. The blocks have different patterns to indicate paths, entrances, and other information.

In some places in Japan, these blocks also have QR codes embedded in them that people can scan to get audio guidance through a nearby speaker. Some very special blocks are even activated by nearby metal objects, like white canes.

From the station I headed toward Hanegi Park, which is only a few minutes’ walk. Hanegi Park has around 60 plum varieties, with both red/pink and white blossoms. The trees are right by the walking path and the blossoms were easy to spot. At the entrance to the park there was a map (in Japanese) with simple voice guidance for orientation.

The Hanegi Park map at the park entrance.

The walk around the park was very pleasant! The plums were not yet in full bloom because we had a cold spell in Tokyo this winter, but I was able to get some nice pictures. The weather that day was lovely—sunny but not too warm—so I felt very lucky.

At the center of the park was a wide area with food stands and some stalls from local shops selling plum-related products. I followed the crowd (since there were no yellow bricks in the park itself) and reached it easily. However, one big challenge is identifying what each stall sells, what kind of food it is, or what products are available. There are some signs, but they are often very small, hard to spot, and difficult to read.

In Japan, restaurants and shops usually have pictures—or sometimes even plastic models—of the food or other things they sell. However, at this small local festival these kinds of pictures were not available. So I had to get up close and hope I could either see a sign or catch a glimpse of someone else’s order—hopefully without looking like I was staring. Otherwise, I could always ask people, which was more fun because it let me interact and improve my Japanese. But sometimes I wished for more agency in getting this simple information, which is often the least accessible.

As I was walking around, I spotted a lovely couple strolling through the festival. One was using a white cane while linking arms with their partner, who narrated the scene and described the different stalls as they explored together.

At festivals in Japan you usually find the same kinds of food:

• Yakisoba (stir-fried noodles)
• Takoyaki (dough balls with pieces of octopus)
• Okonomiyaki (Japanese savory pancake)
• Gyu-kushi (beef skewer)

But instead of eating these, I decided to try some nearby places, so I made my way toward the park exit.

As I was walking, I started hearing a familiar sound—the taiko drum! 🥁 It was a group of primary school children and their teachers performing. I love taiko shows because they don’t require sight at all. Not only is it musical, but the sound, depth, and vibration of the taiko drums are things I can feel throughout my body—especially in my chest. It feels exciting and energizing, and I feel as if I’m there with them, part of the performance itself. I stayed and watched their show, then wrapped up my visit to Hanegi Park and walked around to find a place for lunch.

Note: Not sure if the depth of the sound comes through in the recording, but I recommend using your speakers—instead of headphones—to feel it better. 🔊

My spontaneous visit to Hanegi Park was great! I saw the beautiful plum trees in bloom, bought some delicious pickled plums, enjoyed local culture, and was thrilled by a taiko drum performance. While accessibility in Japan is still developing, I felt this visit was mostly easy and smooth. Even though some things are still difficult—like the signage at food stalls—other things are already quite good. For example, the 🟨 yellow bricks, the 🔉 audio guidance at the park map, and the 🥁 taiko performances.

If you have a chance, go see some plum trees, try some plum jam, or even taste the sour Japanese pickled plums (if you feel adventurous). 💮

In the beautiful Denver, I had the privilege of presenting our work “VeasyGuide: Personalized Visual Guidance for Low-vision Learners on Instructor Actions in Presentation Videos” at ASSETS 2025 (International ACM SIGACCESS Conference on Computers and Accessibility). Even more exciting, VeasyGuide won a 🏆 best paper honorable mention award!

This presentation marked an important milestone in my research on making learning accessible for low-vision learners. Plus, this was my first time attending ASSETS! In this post I will share my experience at ASSETS, and around Denver during my time there.

Feel free to jump ahead to see the full recording of my presentation.

I didn’t know that VeasyGuide won an award. One morning, all of a sudden, I am getting “Congradulations!” messages from friends. Seems like when they go over the online program they saw it. But I, I was oblivious to it! So it was such a nice surprise to wake up one day and realize that we have gotten an award. But let’s get back on track—the conference!

The venue of the conference, the Curtis Hotel at Denver.

This year the conference was held at the Curtis Hotel in Denver, Colorado. I’ve never been to Denver before, but I really liked that city. The downtown had a very nice vibe to it, and also some free public transportation! The shuttle that goes along the 16th street was free to use, which is so nice to see. I usually stay in hostels, which are not always near to the conference venue, so a freee shuttle but was a very nice surprise. The free shuttle goes from the big train station (Union) all the way down almost to the publuc library!

Cool alleyway around 16th street in Denver. So much art around these places that people usually go in to. I think it's great to see this, it's an opportunity to bring life to these kind of areas!

I took the opportunity to also visit the library. It is a very pleasant building, with a vintage kind of atmosphere. I sat down to do some work, at some random location, and as I am getting up to leave. I stumbled on a very interesting sign. And by interesting I mean, very relevant to me!

The sign at the library pointing to the "Large Print" books section.

I was sitting right next to the large print area! What an interesting coicidence right? So I decided to look around through the books there, and I noticed something. The visual style of all books did not exactly match. Some books used a larger font and some smaller. I wonder if there are any regulations on large print books? I tried capturing some of the books I saw there. I think it’s not that easy to notice the side difference in pictures, but when I was there looking at these books, it was a much clearer difference.

A few of the large print books at the library. It is interesting how they use different font size and styling.

This was my first time attending ASSETS, which has a long history since 1994. the conference is much smaller than CHI (which it sprung out of), and was single track until last year. This year though, it shifted to a dual track structure—split between two rooms. However, the entire conference took place on the same floor of the hotel, which was very comfortable. Since everyone is on the same floor, between both of the rooms, there was plenty of opportunities to chat and connect with other researchers and attendees.

It was so inspiring to see so many people interested in accessibility! Everyone is so passionate about their work and the impact they could have through their work; which is something I absolutely share. It was especially impactful to me to connect and chat with other researchers with disabilities. As a researcher with a disability myself, it was very important to see how many others pursue research despite everything! All throughout my life, almost everything is some kind of a struggle, but to me, this is what makes life so interesting, overcoming these difficulties—and I’m not the only one. In a nutshell, to me, ASSETS feels like home.

Another wonderful thing is that I was able to connect with past collegues from The University of Texas at Austin (UT Austin). I spent a summer there as a visiting researcher, and it was such a pleasure to be able to meet again and reunite! Especially, I am glad to see Prof. Amy Pavel, who hosted my stay at UT Austin there. Amy co-authored two papers with me for ASSETS 2025, VeasyGuide and Task Mode, which is a project by Ananya, another amazing researcher from UT Austin.

Group picture with my collegues fromn UT Austin. So glad to reunite with you all there!

Before I move on to share my presentation experience, it’s important to mention that even though it was my first ASSETS, I was able to co-author another full paper (Task Mode) and a poster! The poster was lead by Veronica, who is an amazing researcher from The University of Michigen. It was a delight working on this topic with Veronica. People with ADHD are often left behind, with not much research conducted on ways to help, assist, or improve their daily life. This is especially true for professionals with ADHD, for instance, with managing online communication via email.

Our poster presentation at ASSETS, titled: "A Longitudinal Autoethnography of Email Access for a Professional with Chronic Illness and ADHD: Preliminary Insights".

Now, about VeasyGuide! The presentation and interaction with the listeners was very impactful for me. I got so many wonderful questions during and after the talk! I truly appreciate everyone who watched, asked questions, and provided feedback on this work. Below I put the video recording of the talk and the transcriptions of the Q&A session. There are so many more things to do to improve online learning accessibility for low-vision learners!