I’ve worked on quite a few complex web apps over the years, and one thing that always surprises me is how different an application can feel when you test it with a screen reader. What looks clean and well-organized to a sighted user can become confusing or even unusable for someone who relies on assistive technology. Through trial and error, I’ve picked up some practical ways to make these apps more accessible without overcomplicating the codebase.
One of the biggest challenges I faced was with dynamic content. In a financial dashboard I worked on, data was constantly updating, tables were filtering, charts were refreshing, and numbers were changing in real time. When I tested it with a screen reader, it would often read out large parts of the page again after every small update. This made the experience frustrating and hard to follow.
What helped the most was being more deliberate about how updates were announced. Instead of letting the whole page refresh, I marked specific sections as live regions so the screen reader would only announce the parts that actually changed. This kept the experience calmer and more predictable. I also made sure to use proper semantic HTML wherever possible before reaching for ARIA attributes. Things like using actual <button> elements instead of clickable divs made a noticeable difference in how well the screen reader could navigate the interface.
Another tricky situation came up when we were using micro frontends. Because different parts of the app were built as separate modules, screen readers had trouble understanding the overall structure. Users would move from one section to another and feel like they were starting from scratch each time. There was no clear sense of where they were in the app.
To improve this, we focused on making the main navigation and page structure clearer to assistive technologies. We added proper landmarks so screen readers could recognize the main menu, content area, and other important sections. We also used attributes to indicate which tab or section was currently active. This helped users understand their location in the app without having to reorient themselves constantly. One thing we learned the hard way was that keyboard navigation needed to feel consistent across all modules, otherwise it created a jarring experience.
Looking back, the most useful changes weren’t always the most advanced ones. Simple things like making sure focus states were visible, avoiding unnecessary page reloads, and grouping related content clearly often had the biggest impact. I’ve also found that testing with real screen reader users (even just a couple of times) reveals problems that are hard to catch when you’re only checking against automated tools.
It is my concern, making a complex web app accessible with a screen reader isn’t about adding every possible ARIA attribute. It’s about understanding how someone actually moves through the interface and removing the friction they face. When you keep that in mind, the technical decisions become easier to make.