Accessible design is the practice of creating digital products that can be used effectively by as many people as possible, including people who use assistive technologies or have differing sensory, cognitive, or motor needs. It is not only a moral imperative; it is a practical strategy to improve product quality. When teams operationalize accessibility early, they clarify structure, remove ambiguity, and standardize patterns, which in turn makes interfaces more predictable and efficient for everyone. Accessibility is best understood as a measure of product quality rather than a compliance checkbox. Framing accessibility as a quality signal changes the incentives for teams. Instead of treating accessibility as the last gate before release, teams embed it into foundations, tokens, and components during design and implementation. This up-front investment reduces rework and moves decision making upstream where it is cheaper to change. The result is more resilient components, fewer production defects, and a smoother experience for users across devices and contexts. A quality lens also enables a shared language across crafts. Designers can specify meaningful structure and states. Engineers can implement semantic markup and deterministic focus behavior. Content designers can provide labels, instructions, and error messages that are announced reliably by assistive tech. Each discipline knows how its work contributes to inclusion, so accessibility ceases to be a specialist topic and becomes normal practice across the product lifecycle.

Accessibility Is Integral, Not an Afterthought

Teams that bolt on accessibility late tend to face slowdowns and brittle fixes. They must retrofit contrast, rework patterns that conflict with keyboard navigation, and patch inconsistent focus behavior. The intent might be good, but the approach is reactive, and the result is often fragile. By contrast, treating accessibility as a core design concern creates robust defaults. Components ship with clear states, predictable interactions, and correct semantics, so downstream products inherit good behavior by default and engineering velocity increases as a result.

This integrative approach pays off in moments that matter most. New features rely on shared foundations and tokenized decisions, so updates do not degrade contrast or legibility. When teams adopt a new theme, semantic structure and focus management hold steady across surfaces. Changes are safer because they are anchored in standards that balance brand, usability, and inclusion in a consistent way. In other words, accessibility becomes a multiplier that lets improvements cascade across the system rather than staying local to a single screen.

A common counterargument is that early accessibility slows creative exploration. The stronger position is that constraints foster creativity. When teams know their boundaries, such as minimum contrast for indicators or how focus must move through composite widgets, they can spend their energy on better interaction models instead of arguing over baselines. Constraints do not choke innovation; they channel it toward more inclusive outcomes that scale.

Principles Apply Broadly Across Websites and Mobile Apps

Although this narrative centers on Atlassian products and the Atlassian Design System, the principles generalize to websites and mobile interfaces. Clear semantics, predictable focus, and adequate contrast help on any platform. Likewise, tokenized design decisions for color and typography enable brand-consistent accessibility across themes and densities. Whether building a marketing site, an internal dashboard, or a mobile approval flow, these foundations improve comprehension for new users and reduce error rates for experts. Evaluation is likewise portable. Teams can adapt their toolchains and rituals by combining design-time checks with code-level validation and assistive tech testing. Designers annotate states and interactions in Figma. Engineers run automated checks for common defects in CI and use browser tooling to validate keyboard behavior. Testers validate focus order and announcements using popular screen readers and mobile accessibility services. When these checks are embedded into everyday work, accessibility becomes a continuous quality practice rather than a periodic audit. This cross-platform framing also clarifies trade-offs. For example, a compact data-dense table may help expert users scan quickly, but those gains should not come at the expense of operable keyboard navigation or readable error states. By making the trade-offs explicit and measurable, teams align around solutions that honor both speed and inclusion across surfaces and devices. The result is a coherent experience shaped by shared standards rather than ad hoc fixes applied late in the cycle.

Atlassian’s Accessibility Team and Mission

Atlassian established a dedicated accessibility team within the Atlassian Design System to operationalize inclusion across foundations, workflows, and tooling. The team’s mandate is to build accessibility into the DNA of tokens and components so that products work for everyone by default. This organizational design matters because it moves responsibility into the system layer where decisions scale and endure. It also creates a center of excellence that partners with product teams to apply standards across diverse contexts. The mission includes defining scalable standards, setting guardrails for design trade-offs, and delivering tools that enable makers to apply accessibility without friction. By standardizing decisions in tokens, the team protects downstream experiences from regressions when themes change. By aligning documentation with Figma libraries and code specs, they reduce interpretation gaps between design and engineering. The result is fewer defects and faster delivery because teams spend less time reinventing solutions to known problems. Equally important is the cultural shift. The team normalizes accessibility conversations through office hours, reviews, and cross-craft demos. This constant interaction builds shared fluency among designers, engineers, and content specialists. Over time, accessibility becomes a criterion for quality that leaders track and teams celebrate, rather than a hurdle to clear before release. That cultural foundation is a powerful lever for durable change across a portfolio of products.

Three Guiding Principles in Practice

Accessibility by default means components and foundations meet accessibility-defined standards at creation, so good behavior becomes the default and propagates across products.
Tooling and automation ensure issues are identified as they happen across design and code workflows, making defects cheaper to fix and less likely to ship.
Maker empowerment gives designers and engineers guidance and checks where they work, so teams build inclusive patterns confidently and consistently.

These three principles anchor tactical decisions. Accessibility by default ensures tokens for color and typography start from accessible baselines. Tooling and automation connect design and code through annotations, linters, and CI checks. Maker empowerment gives teams context-sensitive guidance in their daily tools. Taken together, they transform accessibility from ad hoc knowledge into system guarantees that travel with the work. A useful way to judge the maturity of a design system is to ask how much inclusion is encoded rather than remembered. When contrast ratios, keyboard interactions, and semantic structures are embodied in tokens and components, accessibility becomes hard to forget. Conversely, when accessibility depends on individual memory or heroic effort, quality is inconsistent and fragile. Encoding decisions creates guardrails that persist as teams and projects change. Critically, the principles also keep the system honest about trade-offs. Tooling surfaces issues early, but maker empowerment ensures teams understand why a standard exists and how to choose among acceptable options. This combination leads to better decisions rather than blind conformance. It shifts the posture from avoidance of failure to pursuit of quality, which ultimately makes products better for every user.

From Reactive Fixes to Proactive Quality

Before the shift, many accessibility efforts centered on audits and post hoc fixes. That approach can reduce risk for a release, but it rarely fixes root causes. The proactive posture now in place treats each improvement as a system investment. When a token or component is uplifted, every consuming experience benefits, and future features inherit the fix without extra effort. This is how a design system magnifies the impact of accessibility work and shortens time to value for product teams. Proactive quality also reduces cognitive load on makers. Instead of wading through a patchwork of exceptions, designers and engineers work from clean patterns that have predictable behavior. Reviews speed up because there is less to debate and fewer edge cases to reconcile. The shift is not just philosophical; it has measurable downstream effects on velocity and defect rates, as illustrated by the volume of issues resolved after foundational changes rolled out. A skeptic might worry that centralizing decisions in tokens constrains local flexibility. In practice, tokens enable flexibility with safeguards. Teams can theme and adjust within bounds that protect contrast, legibility, and operability. When a truly novel need arises, the system can evolve deliberately so new defaults stay accessible. This approach supports both innovation and inclusion by design.

Roles and Collaboration Across Crafts

Accessibility work succeeds when roles are clear and collaboration is routine. Accessibility leads define standards, steward tokens, and partner with system engineers on semantics and interaction models. Designers own fidelity of states, focus behavior, and error messaging in Figma. Engineers implement keyboard interactions and semantic markup with reference specs and test against core assistive tech scenarios. Content designers craft labels, instructions, and messages that support predictable announcements. The working model relies on shared specifications and annotations that live alongside designs and code. Cross-craft reviews align expectations before handoff so that ambiguity does not turn into defects. Office hours and demos make it easy to raise questions early and socialize patterns that work. These rituals create a healthy feedback loop where the system improves based on real product needs, and product teams benefit from system-level investment. Leadership plays a structural role by building accessibility into OKRs and growth profiles. When accessibility shows up in performance and planning, teams treat it as a first-class dimension of quality. That formal alignment complements the practical tools and processes, ensuring that culture and craft move together in the same direction at the pace of product delivery.

Typography, text weight, and color label design examples from Atlassian foundations.

Auditing and Improving Components

Establishing a System-wide Baseline

Atlassian executed a comprehensive audit of components to understand the current state of visual clarity, interaction design, and assistive technology support. A system-wide audit matters because without an accurate baseline, teams are tempted to optimize for what is most visible rather than what is most impactful. This audit quantified the landscape and identified patterns that suggested systemic fixes rather than isolated patches. In particular, issues in contrast, focus management, and validation consistency surfaced repeatedly across multiple components and contexts.

The audit method emphasized cross-craft evaluation. Designers assessed structure and hierarchy, engineers verified semantics and keyboard interactions, and accessibility specialists tested with screen readers and other assistive technologies. That multifaceted approach prevented tunnel vision. It also built shared ownership, because findings were framed in terms familiar to each craft with clear links to user impact and system-level implications.

A notable strength of the audit was prioritization for scale. Components with broad usage were uplifted first to maximize the downstream effect. This strategy recognizes that accessibility investment returns compound when applied at the system layer. Improving a frequently used input or composite control can pay dividends across dozens of flows and multiple products without repeated effort.

Key Audit Findings

Visual clarity issues were common in inputs and interactive surfaces where border or focus indicators did not meet contrast expectations.
Interaction design gaps showed up in complex components that had drifted toward pointer-optimized behavior at the expense of keyboard operability.
Assistive technology support was inconsistent when elements were announced in confusing sequences or when live regions were overly chatty.

These findings highlight a pattern rather than one-off defects. Visual clarity problems often trace back to token defaults that do not protect contrast sufficiently in light and dark themes. Interaction gaps arise where focus management is not deterministic, causing keyboards to traverse more elements than are necessary or to become trapped. Assistive tech issues signal that semantics and announcements need to be simplified and aligned with predictable task flows. Addressing these at the root yields durable improvements rather than short-term fixes.

The synthesis is clear. A component’s accessibility profile is defined by how tokens, semantics, and interaction logic work together. When those three layers are aligned, users experience consistent feedback, navigable interfaces, and sensible announcements. When they diverge, friction increases quickly, especially for users who do not interact with a mouse or who rely on assistive technologies to understand and control the interface.

Common Enterprise UI Issues to Watch

Insufficient color contrast in borders, icons, and indicators that convey state.
Inconsistent or faint focus indicators that are hard to perceive against complex backgrounds.
Keyboard navigation that is either too linear, forcing excessive steps, or too jumpy, skipping logical groups of controls.

Enterprise UIs often accrue these issues as complexity increases. Teams add capabilities and configuration states while relying on legacy patterns that were optimized around sighted mouse users. Over time, small compromises accumulate and become systemic debt. The remedy is not to remove complexity but to manage it through semantics, focus management, and strong visual affordances that can carry meaning without overreliance on color or subtle shading alone.

A practical lens is to ask whether a user can complete a primary task with just a keyboard at a reasonable pace and with clear feedback. If the answer is no, the component likely needs attention. Similarly, if error states and instructions are ambiguous or not announced in an expected order, users will lose context and confidence. These are solvable problems once teams adopt a consistent system of tokens and behaviors that carry through all components.

Actions Taken to Uplift the System

Cross-craft evaluation aligned on structure, hierarchy, and semantics with shared annotations that clarified expectations.
Prioritization focused on widely used components to maximize scale and reduce downstream friction in product teams.
Design-led remediation reframed issues as design opportunities such as increasing input contrast to make boundaries more legible and states more obvious.

This approach recognizes that remediation is not just about fixing defects; it is about improving the underlying design so the system is more resilient. For example, by lifting border and focus ring contrast at the token level, every input component improves instantly across themes. By revising patterns for validation and error messaging, users receive clear and consistent feedback regardless of the entry method or assistive technology.

The collaboration model mattered as much as the solutions. Shared annotations in Figma, paired with engineering specs, created a single source of truth. Teams did not have to guess what mattered or invent their own accessibility patterns. The result was faster adoption and fewer regressions as uplifted components moved into production.

Measurable Improvements From Remediation

Atlassian reported that more than six thousand accessibility issues were resolved after foundation-driven work took hold. That figure underscores how system changes cascade into product outcomes when applied through tokens and shared components. It also demonstrates the long tail of benefit, because every new feature that consumes the uplifted components inherits the improvements by default.

Measurable gains also showed up in specific components. The date time picker, for instance, saw a dramatic reduction in keyboard steps required for key tasks and improved clarity of focus and validation feedback. These are user-perceivable improvements that reduce cognitive load and task time, especially for keyboard users and people navigating with screen readers. They also reduce support burden because predictable behaviors lower the number of edge cases that confuse users.

The broader lesson is that well-targeted remediation improves both usability and inclusion. When a component becomes easier to navigate and understand, everyone benefits. The cost to maintain the system drops because there are fewer exceptions to manage and less need for local overrides. That is what it looks like when accessibility serves as a driver of product quality and operational efficiency.

Strengthening Design Foundations

Updating Color Tokens for Contrast in All Themes

Color tokens were recalibrated to meet accessibility guidelines for contrast across light and dark themes while preserving the intended brand hierarchy. This is a subtle but high-leverage move. Many visual issues stem not from poor intentions but from token values that are too close together in luminance or that fail under theme shifts. By lifting these at the token layer, designers can still express hierarchy and emphasis while ensuring boundaries and states remain legible in all contexts.

Well-chosen tokens also improve the expressiveness of focus rings, selected states, and error indicators without resorting to overly saturated palettes. They allow components to communicate state using combinations of color, weight, and motion that remain accessible. When combined with clear indicators that do not rely on color alone, the UI retains both clarity and aesthetic integrity.

A practical check for teams is to test tokens across common surfaces, including dense tables, forms, and menus where subtle contrast plays an outsized role in perception. Aligning on a standard palette and validating across themes prevents last-minute fixes when new features roll out to dark mode or when high contrast themes are introduced.

Typography Adjusted for Legibility and Scaling

Typography tokens were adjusted for size and weight to improve legibility across densities and user scaling preferences. These changes help users who increase text size and those reading in high-density layouts where labels can crowd controls. The aim is to make essential text readable at a glance without compromising information density for expert workflows. By aligning typography tokens with legibility thresholds, the system avoids brittle local overrides that can drift over time. Well-structured typographic scales also make it easier to maintain visual rhythm through a product. Consistent steps between sizes reduce visual noise and support clear hierarchy across headings, labels, and body text. When paired with clear line height and spacing conventions, text blocks become easier to scan, and form layouts breathe, which reduces input errors and speeds completion. Finally, typography tokens should be tested with real content, including long labels, error messages, and localized strings that expand. This ensures that truncation strategies and wrap behavior remain predictable and that important information is not lost. Designing for the worst case avoids surprises in production and protects user understanding across languages and screen sizes.

System-level Inheritance That Future-proofs Accessibility

Token inheritance ensures that when foundations improve, all downstream components and experiences inherit those improvements automatically. This is not just a convenience; it is a strategic defense against regression. As teams ship new themes or adopt new surface variants, components remain accessible without manual auditing or patching. Inheritance turns accessibility into a product quality invariant that travels with the design system wherever it is used.

Inheritance also accelerates delivery. Teams can focus on interaction design and content strategy rather than recalibrating colors or typography for every feature. Because tokens encapsulate those decisions, components plug into new flows with confidence. If foundations evolve again, the improvements flow downstream without coordination overhead across dozens of teams and repositories.

To make the most of inheritance, governance matters. Token changes should be versioned, documented, and validated in a staging environment with representative screens. Clear changelogs and migration notes help product teams understand what changed and why, reducing uncertainty and smoothing rollout.

Tools and Guidelines to Validate Foundational Decisions

Foundational changes are only as good as their verification. Designers rely on Figma-based checks and annotations to validate contrast and legibility during design. Engineers use linting and CI tooling to catch issues in code and confirm keyboard and focus behavior. Testers validate with assistive technologies to ensure that semantics and announcements match user expectations. These layers of validation create a safety net that keeps the system honest and prevents regressions as features evolve. Teams can formalize these checks through playbooks that specify when and how to test. For example, every form component might require a checklist that covers focus order, error messaging, and screen reader announcements for both valid and invalid states. Components that open overlays must prove deterministic focus behavior both on open and close. These scenario-based checks go beyond static analysis and connect directly to user tasks. When validation is embedded into everyday tools and rituals, the cost of maintaining accessibility drops. People do not need to switch contexts or wait for specialist reviews to catch common issues. Instead, the system flags problems where the work happens and provides guidance on how to fix them. That is how accessibility scales as part of normal product development.

Tools and Culture for Inclusive Design

Figma-based Accessibility Tooling for Designers

A Figma library of accessibility annotations helps makers consider inclusion at the earliest stages, not just at handoff. These annotations capture expected semantics, focus behavior, and state transitions in a way that aligns with engineering specs. They reduce ambiguity, make edge cases explicit, and accelerate cross-craft understanding. Because they live alongside design artifacts, they become part of the normal workflow rather than a parallel process to remember later. Figma plugins can support color contrast checks and quick audits of text size and weight against target thresholds. When these tools are built into the library or standardized in team workflows, designers can spot issues before they proliferate. That reduces downstream churn and ensures that components are composable without violating standards. As makers iterate on flows and patterns, annotations become a record of intent. They guide implementation decisions and enable more effective reviews by pointing attention to the interactions and announcements that matter most. This is especially valuable in composite controls that require careful focus management, such as date pickers, comboboxes, and modal dialogs.

Contextual Guidance and Shared Documentation

Contextual guidance embedded in design tools and documentation hubs makes accessibility actionable. Instead of generic advice, teams need specific instructions tied to the components they use. For instance, a form pattern should specify how to label inputs, where to place instructions, and how to announce validation errors. A dialog pattern should define focus trapping and return behavior precisely, with examples for keyboard and screen reader interactions. When makers can access this guidance in context, it becomes part of routine decision making rather than something to look up after the fact. Shared documentation also creates consistency. It reduces drift across teams by anchoring practices in a single source of truth. Designers and engineers can reference the same examples and code snippets, which improves reliability and speeds up onboarding for new team members. Over time, this shared body of knowledge becomes a force multiplier that sustains accessibility even as people and projects change. The win is cultural as much as technical. When guidance is easy to find and easy to use, accessibility stops feeling like extra work. It becomes the default way to work, and quality improves without teams having to constantly police each other.

Community, Growth, and Normalized Practice

Atlassian built a community of Accessibility Design Specialists who champion best practices within local teams. These advocates help scale knowledge, field questions, and model practical approaches in live work. Leadership reinforced that culture by embedding accessibility into growth profiles, OKRs, and career development. This alignment makes inclusion a core dimension of craft excellence rather than a peripheral goal. Regular office hours, demos, and reviews keep discussions lively and grounded in real product challenges so the practice stays fresh and relevant as the system evolves.

Cultural infrastructure matters because tools alone are not enough. People need trusted peers who can help interpret guidelines and apply them in messy real-world contexts. They also need recognition for doing the work well, which motivates teams to invest time and creativity into better patterns. By normalizing the conversation, teams replace hesitation with curiosity and move faster with higher quality.

This cultural frame is a model for other organizations. Even without a large central team, you can cultivate a network of advocates, set clear expectations in growth frameworks, and create regular spaces for review. These steps build momentum and make accessibility self-sustaining rather than dependent on a small number of specialists.

System Impact and Future Outlook

Accessibility Improvements That Scale Across Components

The depth of work behind a single component like the date time picker demonstrates how systematic changes propagate through a design system. When tokens improve, components inherit the benefits. When components improve, products that use them gain better defaults. This is how a design system turns targeted effort into widespread impact. Each uplift makes the next feature easier to build, test, and ship with confidence because inclusive behavior is built in and consistently documented. This scaling effect protects product teams from regressions. New features launched against uplifted foundations carry strong semantics, predictable focus, and legible states without extra engineering effort. As teams adopt new themes or adapt components to novel contexts, the system guarantees hold. That reliability shortens review cycles and helps teams focus on user value instead of re-solving foundational issues. The effect is cultural as well as technical. As teams experience the benefits of system-level improvements, buy-in grows. Accessibility moves from being perceived as a constraint to being seen as a source of speed and clarity. That shift encourages teams to seek out further opportunities where system changes could erase recurring pain points.

Six Thousand Issues Resolved and What That Signals

Between June twenty twenty four and June twenty twenty five, Atlassian resolved more than six thousand accessibility issues thanks to foundation-driven work. The magnitude of that figure reflects both pent-up demand and the power of system-level interventions. It shows that when organizations invest in tokens, components, and shared documentation, they can retire classes of defects at scale and prevent them from returning. This is how accessibility gains become durable and reinforce a culture of quality across product lines. Beyond the headline number, the qualitative shift is significant. Clearer standards reduce friction in design reviews. Predictable behavior simplifies testing and cuts support burden. Users experience fewer surprises and navigate with greater confidence. These effects compound as more teams ship against the improved system and as new features roll out on top of stronger foundations. Organizations outside Atlassian can achieve similar outcomes by adopting the same posture. Start with an honest baseline assessment, uplift foundations, instrument the process with contextual guidance and automation, and build a community that normalizes accessibility discussions. Measurable progress will follow, not because teams work harder, but because they work from better defaults that scale.

Shared Standards Raise the Baseline and Sustain Momentum

Shared standards create a common language for quality, which reduces local improvisation and inconsistency. Designers know how to specify focus and validation. Engineers know how to implement semantics and keyboard logic for composite controls. Content designers know how to craft labels and messages that announce predictably. With this alignment in place, teams can push forward on more adaptive foundations and more inclusive defaults that respond to evolving user needs without sacrificing performance or brand expression. Momentum builds as the system proves its value. The first wave of improvements removes obvious friction. The second wave ventures into deeper design trade-offs where inclusive defaults can open up new interaction possibilities. For example, better composability in accessible primitives can enable richer controls that remain operable by keyboard and understandable by screen readers while still feeling lightweight and modern for pointer users. This is not a one-time project but a continuous practice. As platforms evolve and user expectations rise, the design system must adapt. The strongest predictor of future success is the combination of sound foundations, practical tooling, and a healthy culture of shared responsibility. With those elements in place, inclusion and quality tend to move together.

Wrapping Up

If you are looking to raise your accessibility baseline across Atlassian products, the path is clear. Start by assessing your current components and tokens, then uplift the foundations that will give you the highest scale benefit. Embed guidance and automation into the tools your teams already use so accessibility becomes part of everyday work. Build cross-craft rituals that keep the conversation alive and connected to real product decisions. Atlas Bench can help you plan and execute this transformation with a tailored approach grounded in the Atlassian Design System’s latest practices and outcomes.

Interested in learning more? Contact Atlas Bench to book a complimentary consultation with our Certified Atlassian Experts.

Build Accessibility Into Every Design From Day One Start With the Atlassian Design System Today.

Atlas Bench is a Platinum Atlassian Solution Partner with deep Cloud Specialization, helping Data Center customers move beyond migration and fully transform on the Atlassian Cloud Platform. We deliver Atlassian’s System of Work end to end through four collections: Strategy, Teamwork, Service, and Software, connecting planning to execution, aligning teams around outcomes, modernizing service delivery, and accelerating software development.

We are also recognized as an Atlassian World Class Software Development Partner of the Year (Americas), and we bring AI leadership to every engagement. By leveraging Rovo for automation and purpose built agents, we reduce manual work, unlock knowledge across tools, and speed up decision making so organizations realize measurable value faster in cloud.

Behind the Screens – Accessible Design Is Good Design