Monday.com engineers rebuild boards for screen reader accessibility

Why the board rewrite matters

monday.com rebuilt one of its core product surfaces for screen readers without turning the board into a full table redesign, and that choice says a lot about where workplace software is heading. In a Feb. 16 engineering post from Guy Ben-Tov and Eliran Glazer, the company treated accessibility as an enterprise-performance issue: if the interface is hard to navigate with assistive tech, it is harder to adopt, harder to standardize, and easier for large customers to reject.

That framing is important because monday.com sells into organizations that expect software to work across roles, devices, and access needs. The company says it is trusted by more than 250,000 customers worldwide, claims on its homepage that it is trusted by over 60% of the Fortune 500, and offers an Enterprise plan. Once a product sits in that tier of the market, accessibility stops being a nice-to-have and becomes part of the basic contract of usability.

The structural problem under the surface

The core issue was deceptively simple: the board looked like a table, but structurally it was built from a complex set of divs. That distinction matters because screen readers depend on semantic structure, not visual resemblance. A board that only looks tabular can fool the eye while still creating a confusing experience for anyone navigating by keyboard or assistive technology.

monday.com’s engineering team rejected the slower, broader idea of a multi-quarter rewrite and instead designed a semantic structure that assistive technologies could trust. That is the part product teams should pay attention to. Accessibility bugs are often described as polish problems, but this was a systems problem: if the foundation is wrong, adding decorative fixes does not make the product usable.

The company’s support documentation makes the same point in plainer language. Boards may visually resemble tables, but treating them as tables creates an inconsistent and confusing screen-reader experience because boards are complex and dynamic. monday.com’s documentation also describes accessible group summary rows and nested subitems, which signals that the company is trying to preserve the real behavior of the board rather than flatten it into a simpler but inaccurate model.

What monday.com says it is building toward

monday.com’s accessibility materials now say the company is working toward WCAG 2.1 Level AA for the platform. They also say the work includes compatibility with JAWS, NVDA, VoiceOver, ZoomText, and Braille displays, and that accessibility should be embedded into regular development and design processes rather than handled as a late-stage cleanup task.

That matters because those are not abstract compliance markers. They describe the practical difference between a product that can be used independently and one that requires workarounds, help from colleagues, or a different tool altogether. For a platform that claims to organize mission-critical workflows, that is not a side issue. It is part of whether the software actually scales inside an enterprise.

monday.com’s public accessibility statement, last updated March 20, 2026, says web accessibility is at the core of the company’s values and that future features should be inclusive and accessible to people with diverse abilities. The wording is broad, but the implementation question is concrete: can users move around a board with the keyboard, understand group summaries, and read subitems without the interface collapsing into noise? In this case, the answer depends on semantics, not visual design.

Why enterprise buyers should care

The accessibility story lands in the middle of monday.com’s broader business shift. In its Feb. 9, 2026 fourth-quarter and fiscal-year 2025 results, the company said revenue reached $1.232 billion for 2025 and grew 25% year over year. It also said customers with more than $50,000 in ARR represented 41% of total ARR, a sign that larger accounts are becoming a bigger part of the business.

That kind of customer mix changes the stakes. Large organizations do not buy project-management software only for a handful of teams. They standardize around it, build onboarding around it, and expect it to work for people in operations, sales, finance, support, and management without forcing every user into the same interaction pattern. Accessibility, then, becomes tied to procurement, compliance, onboarding, and day-to-day productivity. A board that is awkward for screen reader users is also a sign that the product may not be robust enough for the most demanding buyers.

The enterprise angle also helps explain why this story is bigger than one accessibility fix. If monday.com can show that it can solve structural A11y problems without a disruptive rewrite, that is a signal to customers that the company can improve the product without destabilizing the workflow layer they rely on. For a work OS vendor, that trust is currency.

What product, design, and engineering teams should take from it

The clearest lesson from the board work is that accessibility belongs in architecture decisions, not in final QA. If a board only looks native, but does not behave natively for assistive technology, the problem is structural. That means design systems, component choices, and interaction models all have to be built with screen-reader behavior in mind from the start.

For teams inside monday.com, the practical takeaway is straightforward:

• Keyboard navigation has to feel predictable, not improvised.

• Layouts need to stay readable when the visual grid is translated into spoken structure.

• Interactions should expose the real hierarchy of the board, including group summaries and nested subitems.

• Accessibility work should be treated as product quality work, because that is what enterprise customers experience.

The most useful part of this story is not that monday.com talked about accessibility. It is that the company showed how to make a core product surface more usable without pretending the problem was cosmetic. In a market where larger customers increasingly standardize on software that has to work for everyone, that is the kind of engineering discipline that supports growth instead of slowing it down.