AI-Powered Accessibility Automation for E-commerce Platform

mercado_libre · E-commerce · 2025 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.4 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Accessibility support for a large e-commerce engineering organization

Mercado Libre's accessibility team needed to support hundreds of designers and developers with questions, audits, handoffs, and fix reviews without becoming the bottleneck for inclusive product work.

Constraints:

• hundreds of designers and developers
• accessibility expertise scarcity
• internal standards and design-system grounding
• need to avoid hallucinated accessibility guidance
• manual review capacity limits

Architecture

Mercado Libre built several accessibility automations around trusted internal knowledge: a RAG Slack assistant, audit-ticket enrichment, Figma handoff annotations, and a Jira/GitHub review workflow that triages fixes for human accessibility experts.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  a11y-slack-assistant["A11Y Slack assistant"]
  trusted-accessibility-corpus["Trusted accessibility corpus"]
  ticket-enrichment-workflow["Ticket enrichment workflow"]
  figma-handoff-assistant["Figma handoff assistant"]
  jira-and-github-integration["Jira and GitHub integration"]
  ai-ticket-review-agent["AI ticket review agent"]
  traffic-light-review-classifier["Traffic-light review classifier"]
  human-accessibility-experts["Human accessibility experts"]
  a11y-slack-assistant --> trusted-accessibility-corpus
  trusted-accessibility-corpus --> ticket-enrichment-workflow
  trusted-accessibility-corpus --> figma-handoff-assistant
  jira-and-github-integration --> ai-ticket-review-agent
  ai-ticket-review-agent --> traffic-light-review-classifier
  ticket-enrichment-workflow --> traffic-light-review-classifier
  traffic-light-review-classifier --> human-accessibility-experts
  human-accessibility-experts --> trusted-accessibility-corpus

Components

Data flow

Accessibility questions and tickets are grounded in internal resources, standards, and design-system context, then routed through Slack, ticket enrichment, Figma handoffs, and Jira/GitHub review automation.

Why this architecture

The architecture ties LLM output to trusted standards because incorrect accessibility guidance would create hallucinated fixes and undermine inclusion work.

Models used: large language model with Retrieval-Augmented Generation · AI agent for ticket and PR review

Scale

• The workflow supports hundreds of designers and developers by filtering which tickets need additional manual review.
  “This workflow filters which tickets need additional manual review, allowing us to focus our team’s time.”article, implied

  “This workflow filters which tickets need additional manual review, allowing us to focus our team’s time.”article, implied

Alternatives considered (roads not taken)

Image-based Figma annotations in the first release

Rejected because: The team chose text-only responses because they were more accurate than image-based annotations.

Manual review of every resolved accessibility ticket

Rejected because: The traffic-light classifier lets specialists focus on tickets that need additional manual review.

Ungrounded LLM accessibility advice

Rejected because: The assistant uses internal standards and resources to avoid hallucinated accessibility guidance.

Patterns

rag-retrieval (retrieval)

The A11Y assistant grounds answers in internal documentation, training materials, historical queries, reported tickets, and the design system.

tool-use-orchestration (orchestration)

The resolved-ticket review workflow pulls Jira tickets, inspects linked GitHub PRs, asks an AI agent to assess evidence and implementation quality, then stores classifications.

human-in-the-loop-gate (safety)

The agent triages which resolved accessibility tickets need additional manual review instead of replacing the accessibility team's judgment entirely.

Tradeoffs

How the Figma assistant should return accessibility guidance.

Chose text-only guidance over image-based annotations.

Rationale: The team says text responses are currently more accurate, even though image annotations might feel more direct.

Gotchas (what bit them)

LLM accessibility advice can hallucinate if it is not tied to trusted internal standards.

Root cause: Accessibility guidance depends on local design-system patterns, prior decisions, and internal implementation conventions.

Resolution: Use RAG over Mercado Libre resources and require responses backed by verified information.

Accessibility audit tickets can overwhelm teams that lack deep accessibility expertise.

Root cause: Manual audits include technical assistive-technology details, reproduction steps, and WCAG criteria that are hard for non-specialists to translate into fixes.

Resolution: Enrich generated tickets with user-impact explanations, concrete recommendations, and verification steps.

Design handoffs often miss semantic accessibility annotations.

Root cause: Designers may not know how to annotate headers, links, buttons, groups, or dynamic areas before implementation begins.

Resolution: Use a screen-image assistant that produces a visual map and recommends semantic annotations for Figma handoffs.

Evaluation

The article describes workflow utility and review triage but does not publish quantitative model-quality or time-savings metrics.

Outcomes

• Mercado Libre reports faster accessibility support, richer remediation tickets, better design handoffs, and focused manual review of resolved issues.
• The work is framed as responsible experimentation rather than a finished replacement for accessibility experts.

Mercado Libre engineering article; no quantitative impact metrics are included.