github·May 15, 2026·3 min readCurated summary

Building a general-purpose accessibility agent—and what we learned in the process

GitHub is piloting a general-purpose accessibility agent that answers accessibility questions and automatically fixes straightforward issues in front-end code. The agent has reviewed 3,535 pull requests and resolved 68% of identified issues, especially problems involving structure, control names, status messages, text alternatives, and keyboard focus. GitHub’s experience shows that an accessibility agent is most effective as an augmentation of human expertise, supported by a strong foundation of manually documented accessibility work. ## Goals and Results - The agent serves two purposes: - Provide just-in-time accessibility guidance through GitHub Copilot CLI and VS Code. - Detect and automatically remediate simple, objective accessibility issues before production. - It evaluates pull requests that modify front-end code. - Its five most common issue categories are: - Making structure and relationships understandable to assistive technologies. - Giving interactive controls clear, concise names. - Ensuring users receive important status announcements. - Providing text alternatives for non-text content. - Maintaining a logical keyboard focus order. - Example fixes can identify mismatches between visual order and screen-reader reading order, then suggest code changes that developers can commit directly. ## An Augmenting, Not Universal, Tool - GitHub frames accessibility through the social model of disability: barriers are often created by how digital environments are designed and built. - The agent is intended to help engineers remove those barriers, not “solve” accessibility independently. - It is not a silver bullet capable of handling every accessibility scenario. - Clearly limiting its responsibility helped GitHub launch the experiment more quickly and gain broader internal support. ## Why Manual Accessibility Work Matters - New and upcoming regulations, including the European Accessibility Act and the Americans with Disabilities Act’s planned WCAG 2.1 AA requirements, increase the importance of accessibility investment. - Organizations without established processes for manually identifying and fixing accessibility problems will be at a disadvantage. - GitHub already had a mature issue-management process containing: - Structured problem reports. - Reproduction steps. - Severity, service-area, and WCAG metadata. - Links to fixing pull requests. - Acceptance criteria. - Centralizing these issues in one repository made the collection a valuable reference corpus for the agent. ## Using Historical Issues as Training Material - The agent examines past accessibility issues and related pull requests to find applicable code and language patterns. - LLMs’ fuzzy matching can be useful here because it helps connect new problems with similar historical examples. - Generic instructions such as “follow accessibility best practices” are insufficient. - LLMs often reproduce accessibility antipatterns because their training data contains decades of inaccessible code. - Manually cataloged issues and organization-specific fixes provide contextual examples that are more useful than short, generic accessibility checklists. GitHub’s experience suggests that teams should first build reliable human processes for reporting and remediating accessibility issues. Once that structured knowledge exists, an agent can help apply it consistently and efficiently—while remaining a complement to, rather than a replacement for, accessibility expertise.

Read original(opens in new tab)

FrontendLarge Language ModelsAccessibilityGithub Copilot+3

kakao·Apr 22, 2026·3 min readCurated summary

The Calendar We Designed for KakaoTalk Booking

KakaoTalk Reservation built a time-block calendar to help sellers understand inventory and bookings more easily than with a card list. The main challenge was arranging bookings with different start times and durations so that they remain readable and use space efficiently. The solution combines sorting rules, graph-based layout calculation, DFS, and additional expansion logic for edge cases. ## Product Requirements - The calendar is designed for the seller-facing reservation management center. - Each time slot can contain up to 10 bookings. - A booking can last from one to six hours. - Booking blocks should be displayed as clearly as possible without leaving unnecessary gaps. - The input data provides booking start and end times, while the frontend must calculate the visual layout. ## Booking Placement Rules - **Sort by earliest start time** - Earlier bookings are placed first to match the seller’s natural workflow. - This also supports the typical visual scanning order from the upper-left toward the lower-right. - **For bookings starting at the same time, sort by longest duration** - Longer bookings can block shorter bookings from expanding. - Placing them first gives them enough space and allows later bookings to occupy the remaining areas more effectively. ## Graph-Based Expansion - The bookings are modeled as nodes in a graph. - Each node stores relationships with preceding and following overlapping bookings. - A depth-first search calculates: - Each node’s depth, representing its horizontal position. - The maximum distance to the final booking in its connected path. - These values are used to calculate: - `left`: the node’s horizontal starting position. - `width`: how far the booking can expand across available space. - Nodes at the far-left edge of the graph are processed first, allowing the bookings to fill the calendar while respecting overlaps. ## Handling Layout Exceptions - The initial graph and DFS calculation did not always fill all available space. - Problems occurred when: - Multiple root nodes existed. - An upper root node had a longer path than a lower root node. - Connected nodes were constrained by earlier width calculations. - The implementation searches for unused gaps between neighboring nodes. - When multiple gaps exist, connected nodes are expanded by the smallest available amount needed to close the gaps. - A gap is detected when the next node’s `left` position is greater than the current node’s `left + width`. ## Lessons from the Implementation - A calendar that appears visually simple can require substantial algorithmic design. - Frontend developers are responsible not only for rendering data, but also for deciding how that data should be presented to users. - The calendar is treated as an evolving implementation that will be refined as new bugs, data patterns, and better algorithms are discovered. The practical approach is to begin with clear sorting rules, represent overlapping bookings as a graph, use DFS to determine layout constraints, and add targeted post-processing for unused space and edge cases.

Read original(opens in new tab)

FrontendUser InterfaceData VisualizationCalendar Ui+2

toss·Feb 26, 2026·3 min readCurated summary

Easy-to-use Toss Front SDK

The post argues that an SDK’s stability depends not only on its internal implementation but also on how safely users can interact with it. Low-level APIs may expose every operation clearly, yet still allow human errors such as missing event handlers or cleanup. The recommended solution is an intent-driven Facade interface that simplifies common workflows, prevents misuse, and still provides low-level escape hatches for advanced cases. ## Designing an SDK That Is Easy to Use - Toss Place develops an external SDK for Toss Front payment terminals. - The SDK allows third-party developers to build plugin apps that integrate with Toss services and run on the terminal. - A simple-looking server API might require users to: - Open a server. - Register connection, message, and error handlers. - Remove handlers. - Close the server. - This approach exposes implicit responsibilities to SDK users: - A message callback might never be registered after a connection. - Handlers might not be removed before shutdown. - Improper cleanup can cause memory leaks and operational issues. - Therefore, third-party implementation mistakes can directly affect platform reliability. - A safer interface hides unnecessary internal steps: ```ts const server = await sdk.start({ onConnection, onMessage }); await server.stop(); ``` ## Facade as an Intent-Driven Interface - The Facade pattern is commonly described as wrapping a complex subsystem with a simpler interface. - In SDK design, its deeper purpose is to reorganize complexity around user intent rather than merely hide functionality. - Users should express goals such as: - “Start a server” - “Upload a file” - “Request a payment” - Internal concerns—including authentication, retries, state management, listener registration, and cleanup—should be handled by the SDK. - AWS CDK illustrates this distinction: - **L1 constructs** closely represent raw CloudFormation resources and provide fine-grained control. - **L2 constructs** provide intent-based APIs, such as creating a versioned S3 bucket with `versioned: true`, while handling the underlying configuration automatically. - The goal of a Facade is to reduce cognitive load and coupling, not simply to conceal every lower-level capability. ## Combining High-Level and Low-Level APIs - A well-designed SDK should provide both abstraction levels: - **High-level Facade:** Handles the roughly 80% of common use cases through complete workflows. - **Low-level APIs:** Serve as escape hatches for the roughly 20% of specialized cases requiring precise control. - In the example: - The Facade’s `start()` method opens the server, registers listeners, coordinates connections, and returns a unified server handle. - Low-level APIs separately expose operations such as `open`, `close`, `send`, `disconnect`, and event listeners. - This layered design improves immediate developer experience while preserving long-term compatibility and extensibility. ## Trade-offs and Escape Hatches - Higher-level abstractions inevitably reduce some flexibility. - Specialized requirements—such as keeping one connection while closing others—may not fit the Facade workflow. - As orchestration becomes more sophisticated, the SDK maintainers inherit additional implementation and maintenance costs. - Low-level escape hatches are therefore essential: users should be able to bypass the Facade when they need detailed control. ## Practical Recommendation Design SDK APIs around user intent and automate error-prone lifecycle management wherever possible. Offer a concise Facade for common workflows, but retain well-defined low-level interfaces so advanced users are not blocked by the abstraction.

Read original(opens in new tab)

FrontendAPI DesignSoftware ArchitectureInterface Design+4

woowahan·Dec 10, 2025Original article

We refactor culture just like code. (opens in new tab)

The Commerce Web Frontend Development team at Woowa Brothers recently underwent a significant organizational "refactoring" to manage the increasing complexity of their expanding commerce platform. By moving away from rigid, siloed roles and adopting a flexible "boundary-less" part system, the team successfully synchronized disparate services like B Mart and Baemin Store. This cultural shift demonstrates that treating organizational structure with the same iterative mindset as code can eliminate operational bottlenecks and foster a more resilient engineering environment. ### Transitioning to Boundary-less Parts * The team abandoned traditional division methods—such as project-based, funnel-based, or service-vs-backoffice splits—because they created resource imbalances and restricted developers' understanding of the overall service flow. * Traditional project-based splits often led to specific teams being overwhelmed during peak periods while others remained underutilized, creating significant delivery bottlenecks. * To solve these inefficiencies, the team introduced "boundary-less parts," where developers are not strictly tied to a single domain but are encouraged to work across the entire commerce ecosystem. * This structure allows the organization to remain agile, moving resources fluidly to address high-priority business needs without being hindered by departmental "walls." ### From R&R to Responsibility and Expandability (R&E) * The team replaced the traditional R&R (Role & Responsibility) model with "R&E" (Responsibility & Expandability), focusing on the core principle of "owning" a problem until it is fully resolved. * This shift encourages developers to expand their expertise beyond their immediate tasks, fostering a culture where helping colleagues and understanding neighboring domains is the standard. * Work is distributed through a strategic sync between team and part leaders, but team members maintain the flexibility to jump into different domains as project requirements evolve. * Regular "part shuffling" is utilized to ensure that domain knowledge is distributed across the entire 20-person frontend team, preventing the formation of information silos. ### Impact on Technical Integration and Team Resilience * The flexible structure was instrumental in the "ONE COMMERCE" initiative, which required integrating the technical stacks and user experiences of B Mart and Baemin Store. * Because developers had broad domain context, they were able to identify redundant logic across different services and abstract them into shared, common modules, ensuring architectural consistency. * The organization significantly improved its "Bus Factor"—the number of people who can leave before a project stalls—by ensuring multiple engineers understand the context of any given system. * Developers evolved into "domain-wide engineers" who understand the full lifecycle of a transaction, from the customer-facing UI to the backend administrative and logistics data flows. To prevent today's organizational solutions from becoming tomorrow's cultural legacy debt, engineering teams should proactively refactor their workflows. Moving from rigid role definitions to a model based on shared responsibility and cross-domain mobility is essential for maintaining velocity and technical excellence in large-scale platform environments.

FrontendAutomationCode ReviewRefactoring+3

naver·Dec 8, 2025Original article

When Design Systems Meet AI: Shifts (opens in new tab)

The integration of AI into the frontend development workflow is transforming how markup is generated, shifting the developer's role from manual coding to system orchestration. By leveraging Naver Financial’s robust design system—comprised of standardized design tokens and components—developers can use AI to automate the translation of Figma designs into functional code. This evolution suggests a future where the efficiency of UI implementation is dictated by the maturity of the underlying design system and the precision of AI instructions. ### Foundations of the Naver Financial Design System * The system is built on "Design Tokens," which serve as the smallest units of design, such as colors, typography, and spacing, ensuring consistency across all platforms. * Pre-defined components act as the primary building blocks for the UI, allowing the AI to reference established patterns rather than generating arbitrary styles. * The philosophy of "knowing your system" is emphasized as a prerequisite; AI effectiveness is directly proportional to how well-structured the design assets and code libraries are. ### Automating Markup with Code Connect and AI * Figma's "Code Connect" is utilized to bridge the gap between design files and the actual codebase, providing a source of truth for how components should be implemented. * Specific "Instructions" or prompts are developed to guide the AI in mapping Figma properties to specific React component props and design system logic. * This approach enables the transition from "drawing" UI to "declaring" it, where the AI interprets the design intent and outputs code that adheres to the organization’s technical standards. ### Challenges and Limitations in Real-World Development * While AI-generated markup provides a strong starting point, it often requires manual intervention for complex business logic, state management, and edge-case handling. * Maintaining the "Instruction" set requires ongoing effort to ensure the AI stays updated with the latest changes in the component library. * Developers must transition into a "reviewer" role, as the AI can still struggle with the specific context of a feature or integration with legacy code structures. The path to fully automated frontend development requires a highly mature design system as its backbone. For teams looking to adopt this paradigm, the priority should be standardizing design tokens and component interfaces; only then can AI effectively reduce the "last mile" of markup work and allow developers to focus on higher-level architectural challenges.

FrontendAIDesign SystemsDesign Tokens+2

woowahan·Dec 5, 2025Original article

In Search of Lost Accessibility | Woowa (opens in new tab)

Achieving a high accessibility score on automated tools like Lighthouse does not always translate to a functional experience for users with visual impairments. This post explores how a team discovered that their "high-scoring" product actually required over 300 swipes for a screen reader user to reach a purchase button, leading them to overhaul their approach. By focusing on actual screen reader behavior rather than just checklists, they successfully transformed a fragmented interface into a streamlined, navigable user journey. ### Navigational Structure with Landmarks and Headings * The team implemented a clear hierarchy using landmarks (header, main, footer) and heading levels, which allows screen reader users to jump between sections via tools like the iOS VoiceOver "Rotor." * To ensure consistency, they developed a reusable component that automatically wraps content in a `<section>` and links it to a heading using the `aria-labelledby` attribute. * They addressed a common CSS pitfall: because setting `list-style: none` can cause VoiceOver to stop recognizing elements as a list, they explicitly added `role="list"` to maintain structural context for the user. ### Consolidating Fragmented Text for Readability * Information that should be heard as a single unit, such as prices (e.g., "990" and "Won"), was often fragmented into separate swipes; the team corrected this by using template literals to merge data into single strings. * For cases where visual styling required separate DOM elements, they used a "NoScreen" component strategy: hiding the visual elements from screen readers with `aria-hidden="true"` while providing a single, visually hidden description for the screen reader to announce. * The team noted that `aria-label` on generic containers like `<span>` or `<div>` is often ignored by iOS VoiceOver, making screen-reader-only text a more reliable method for cross-platform accessibility. ### Defining Roles for Interactive Elements * The team identified that generic buttons like "View All" lacked context, so they updated them with specific labels (e.g., "View all 20 reviews") to clarify the outcome of the interaction. * They ensured that all interactive elements have clearly defined roles, preventing the ambiguity that occurs when a screen reader identifies an element as a "button" without explaining its specific purpose or the data it controls. True accessibility is best measured by the physical effort required to complete a task, such as the number of swipes or touches. Developers should move beyond automated audits and regularly perform manual testing with screen readers like VoiceOver or TalkBack to ensure their services are genuinely usable for everyone.

FrontendWeb AccessibilityAriaSemantic Html+2

woowahan·Dec 5, 2025Original article

아한형제들 기술블로그 (opens in new tab)

The 7th Woowacourse crew has successfully launched three distinct services, demonstrating that modern software engineering requires a synergy of technical mastery and "soft skills" like product planning and team communication. By owning the entire lifecycle from ideation to deployment, these developers moved beyond mere coding to solve real-world problems through agile iterations, user feedback, and robust infrastructure management. The program’s focus on the full stack of development—including monitoring, 2-week sprints, and collaborative design—highlights a shift toward producing well-rounded engineers capable of navigating professional environments. ### The Woowacourse Full-Cycle Philosophy * The 10-month curriculum emphasizes soft skills, including speaking and writing, alongside traditional technical tracks like Web Backend, Frontend, and Mobile Android. * During Level 3 and 4, crews transition from fundamental programming to managing team projects where they must handle everything from initial architecture to UI/UX design. * The process mimics real-world industry standards by implementing 2-week development sprints, establishing monitoring environments, and managing automated deployment pipelines. * The core goal is to shift the developer's mindset from simply writing code to understanding why certain features are planned and how architecture choices impact the final user value. ### Pickeat: Collaborative Dining Decisions * This service addresses "decision fatigue" during group meals by providing a collaborative platform to filter restaurants based on dietary constraints and preferences. * Technical challenges included frequent domain restructuring and UI overhauls as the team pivoted based on real-world user feedback during demo days. * The platform utilizes location data for automatic restaurant lookups and supports real-time voting mechanisms to ensure democratic and efficient group decisions. * Development focused on aligning team judgment standards and iterating quickly to validate product-market fit rather than adhering strictly to initial specifications. ### Bottari: Real-Time Synchronized Checklists * Bottari is a checklist service designed for situations like traveling or moving, focusing on "becoming a companion for the user’s memory." * The service features template-based list generation and a "Team Bottari" function that allows multiple users to collaborate on a single list with real-time synchronization. * A major technical focus was placed on the user experience flow, specifically optimizing notification timing and sync states to provide "peace of mind" for users. * The project demonstrates the principle that technology serves as a tool for solving psychological pain points, such as the anxiety of forgetting essential items. ### Coffee Shout: Real-Time Betting and Mini-Games * Designed to gamify office culture, this service replaces simple "rock-paper-scissors" with interactive mini-games and weighted roulette for coffee bets. * The technical stack involved challenging implementations of WebSockets and distributed environments to handle the concurrency required for real-time gaming. * The team focused on algorithm balancing for the weighted roulette system to ensure fairness and excitement during the betting process. * Refinement of the service was driven by direct feedback from other Woowacourse crews, emphasizing the importance of community testing in the development lifecycle. These projects underscore that the transition from a student to a professional developer is defined by the ability to manage shifting requirements and technical complexity while maintaining a focus on the end-user's experience.

FrontendAndroidDistributed SystemsMonitoring+4

naver·Nov 24, 2025Original article

Naver TV (opens in new tab)

This session from NAVER ENGINEERING DAY 2025 explores the implementation of visual data tools to interpret complex user behavior within Naver’s Integrated Search. By transforming raw quantitative click logs into intuitive heatmaps and histograms, the development team provides a clearer understanding of how users navigate and consume content. This approach serves as a critical bridge for stakeholders to find actionable evidence for service improvements that are often obscured by traditional data analysis. ### Visualizing User Intent through Heatmaps and Histograms * Click logs from Naver Integrated Search are converted into heatmaps to pinpoint exactly where users are focusing their attention and making their "first clicks." * Histograms are utilized alongside heatmaps to provide a temporal and frequency-based perspective on user interactions, making it easier to identify patterns in data consumption. * The visualization system aims to help developers and designers who struggle with raw quantitative data to gain an immediate, intuitive grasp of user experience (UX) performance. ### Handling Dynamic Data in Real-Time Search Services * The system is designed to respond to the "real-time evolution" of Naver Search, where content and UI layouts change frequently based on trends and algorithms. * The FE Infrastructure team shared technical know-how on collecting and processing client-side logs to ensure data accuracy even as the search interface evolves. * Significant trial and error were involved in developing a visualization framework that remains consistent and reliable across diverse search result types and user devices. ### Practical Application for Service Improvement * By using heatmaps as a primary diagnostic tool, teams can move beyond speculative design and base UI/UX updates on concrete visual evidence of user friction or engagement. * The technology allows for the identification of "dead zones" or overlooked features that may require repositioning or removal to streamline the search experience. * Integrating these visual tools into the development workflow enables faster feedback loops between data analysis and front-end implementation. For organizations managing high-traffic web platforms, moving from raw data tables to visual behavior mapping is essential for understanding the nuance of user interaction. Implementing a robust heatmap and histogram system allows teams to validate product hypotheses quickly and ensures that service updates are driven by actual user behavior rather than just aggregate metrics.

FrontendData VisualizationHeatmapLog Analysis+2