Aria

3 posts

figma3 min readCurated summary

Building Accessibility Into a Canvas-Based Product | Figma Blog

Figma’s canvas-based rendering enables performance features such as infinite zoom and real-time collaboration, but it removes the browser’s built-in accessibility support. To restore that support, Figma built a synchronized “Mirror DOM” that represents the canvas in ordinary DOM elements for screen readers and keyboard users. The system combines an internal accessibility tree, React-rendered mirror elements, bidirectional selection syncing, and announcements for non-navigational changes. ## Why Canvas Requires a Different Accessibility Strategy - Figma renders designs on a canvas rather than with traditional HTML and DOM. - This improves performance but leaves the browser’s accessibility tree nearly empty. - Unlike a conventional web app with semantic elements such as `<button>`, `<p>`, and `<img>`, Figma’s canvas effectively has only one focus-holding `<input>`. - Without additional work, screen readers cannot navigate or meaningfully interpret the layers in a Figma file. ## Synthesizing an Accessibility Tree - Browsers normally derive an accessibility tree from the DOM, semantic HTML, ARIA attributes, and computed state. - Figma created its own internal accessibility tree to provide equivalent non-visual information for each design layer. - Each layer receives an accessible summary describing the role and content a screen reader should announce. - Summaries vary according to context: - In prototypes, editing-related layers can be omitted, while text and interactive roles are preserved for viewers. - In editing mode, structures such as autolayout frames need to remain available. - The tree is flattened by removing omitted nodes and connecting their relevant descendants. - Figma builds the tree initially, then applies surgical updates as documents change instead of rebuilding everything. ## Rendering the Mirror DOM - A recursive React component converts the internal accessibility tree into DOM elements. - Each component subscribes to accessibility data for one design layer and renders its role, label, and children. - React’s incremental updates help keep DOM changes minimal as the design changes. - The resulting elements are invisible to sighted users but available to assistive technologies. ## Synchronizing Canvas and Screen Reader Interaction - Figma maintains bidirectional synchronization between the visual canvas and the Mirror DOM. - Selecting a layer on the canvas moves focus to the corresponding DOM element. - When a screen reader user navigates the Mirror DOM, Figma updates the canvas selection accordingly. - This connects non-visual navigation with the editor’s visual state. ## Announcing Changes - A separate announcement system communicates changes that are not primarily navigational. - It reports actions such as nudging objects, switching tools, and other updates that would normally be apparent visually. - Together with the Mirror DOM, these announcements help screen reader users understand both the document structure and ongoing editor activity. Figma’s approach shows that accessibility can be rebuilt for canvas applications by maintaining a semantic representation alongside the rendering layer. Applications that prioritize canvas performance should provide a synchronized accessibility model rather than relying on the canvas itself to expose meaning to assistive technologies.

Read original(opens in new tab)
woowahanOriginal 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.

figma2 min readCurated summary

A step forward in our accessibility efforts | Figma Blog

Figma argues that making design accessible requires enabling people of all abilities to participate throughout the design process. Its new prototype screen reader beta addresses a major gap for blind and low-vision users by making prototype content readable and navigable with assistive technology. The company presents this as an important step, while acknowledging that substantial accessibility work remains. ## Prototype Screen Reader Beta - Previously, screen readers encountered Figma prototypes as an essentially empty canvas, making text, images, and interactive content inaccessible. - The beta supports: - Text notes - Image alt text - Navigation through prototypes - Buttons and keyboard actions such as tabbing - Because Figma designs are not built as HTML, the company created an HTML representation of prototypes specifically for screen readers. - The beta was launched to gather feedback and improve the experience; it later became an open beta for everyone. ## Accessibility Work Underway - Figma has also introduced: - Dark mode and improved color-contrast compliance - Live captions for audio chat - A platform-wide accessibility assessment by Deque - Greater support for accessibility plugins, widgets, and community files - The company is developing reusable UI components and internal tools that encourage keyboard and screen reader compatibility. - Accessibility is being incorporated into team expectations, product development, and early user testing through alpha and beta programs. ## Remaining Challenges - Figma recognizes that more screen reader and general accessibility support is needed. - Planned capabilities include allowing users to: - Add alt text - Assign ARIA roles to components - Define prototype tab order - The company emphasizes that accessibility improvements should be developed collaboratively with the community. Figma’s recommendation in practice is to continue testing accessibility features with users who rely on assistive technology and to treat accessibility as an ongoing part of product design and engineering rather than a one-time update.

Read original(opens in new tab)