{
  "id": 12378537,
  "title": "AccessBuild Day 3: Auto-Scanning Is Live. Here's What I Learned.",
  "url": "https://urgent.news/2026/10/06/accessbuild-day-3-auto-scanning-is-live-heres-what-i-learned",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-10-06T12:53:16.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/okeke_chukwudubem_5f3bf49/accessbuild-day-3-auto-scanning-is-live-heres-what-i-learned-59h8"
  },
  "original_language": "en",
  "account": "On the third day of AccessBuild, the API has evolved from a simple calculator to a memory with the ability to auto-scan Android UI tree XML files, parse every interactive element, score accessibility, and save results to Supabase. The new /scan endpoint enables users to submit raw UI tree dumps, which the system then analyzes, classifies each element, checks for accessibility labels, and assigns a grade from A to F. The audit results are then stored in the database.\n\nThe development of the API progressed significantly since Day 1 when it was only capable of scoring manually inputted elements. By Day 3, it had grown to include a persistent, repeatable audit process with an /audits/recent endpoint displaying recent audit history. Previously, there was no auto-scan endpoint, /stats endpoint, or history tracking.\n\nIn a demonstration, the first auto-scan of a test banking login screen yielded a grade of D (40% accessible), indicating that most elements were invisible to screen readers. The audit was saved in the database and recommended urgent fixes, as an app with such a low score would be unusable for blind customers.\n\nSeveral deployment issues were encountered during the development process, including Render not finding the port, missing files such as models.py, and build cache holding onto old code. These problems required debugging efforts, consuming three hours of work compared to mere ten minutes of actual feature development. The resolution involved updating the start command to utilize $PORT, creating the missing files, clearing the build cache, and redeploying.\n\nWith the new features and fixes in place, the API now includes a comprehensive pipeline: request → parse → score → save → respond. The next steps for Day 4 involve building a public dashboard showcasing audited apps and scores, connecting real app scanning to the Phone Agent's UI tree output, and commencing scans of Nigerian banking apps for practical application. The repository for the API can be found at github.com/Dexter2344/accessbuild-api.",
  "summary": "Day 3 of AccessBuild. The API is no longer just a calculator. It has a memory now. What I Built Today Yesterday, the API could only score elements you pasted in manually. Today, it parses real Android UI tree XML, extracts every interactive element, scores it, and saves the result to Supabase. The new /scan endpoint accepts a raw UI tree dump. It walks through every node, classifies each element…",
  "key_points": [
    "Auto-scan feature added to AccessBuild API",
    "/scan endpoint processes UI tree dumps for accessibility analysis",
    "Grade D received by test banking login screen audit"
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}