Abstract
Sociotechnical Synthesis
Introduction
My two thesis projects, the technical report and STS research paper, are connected through a shared question: does automating accessibility actually help disabled users, or does it substitute for the inclusion that genuine access requires? My capstone project, Dream, is an AI-powered browser built on Chromium that lets users with motor, cognitive, or visual disabilities navigate the web through natural language commands. My STS research paper examines the AccessiBe case, in which the FTC fined an AI accessibility overlay company one million dollars for making deceptive claims about its product's ability to make websites accessible. Both projects are concerned with the difference between what automated accessibility solutions promise and what disabled users actually experience. The technical project attempts to close that gap from the user side, and the STS paper investigates how a commercially deployed attempt to close it from the developer side failed, and why.
Summary of Capstone Project
Dream is an open-source AI browser that is built as a fork of the Chromium engine. It integrates an AI sidebar that allows users to perform multi-step web tasks through natural language. Most websites lack proper ARIA labels and semantic markup. Dream uses visual recognition to look at what is actually displayed on the screen rather than relying on the underlying code. The browser takes screenshots and sends them to a vision-language model that returns a series of clicks, keystrokes, and navigation events. This works very reliably on poorly structured websites that traditional assistive technologies cannot handle, such as sites built on canvas-based interfaces like Google Sheets. The system breaks down high-level user goals into individual browser actions and supports Chrome profile import so users can remain authenticated across services. We evaluated Dream through in-person usability sessions focused on booking a DMV appointment, a task that is meant to be representative of the multi-step workflows that present the greatest barriers to users with disabilities. The results showed significant performance gains for users who struggled most with manual navigation. This confirms that AI-driven browser automation can serve as a beneficial assistive layer when designed around real-world usage rather than web standards alone.
Summary of STS Research Paper
My STS paper, "Automation, Agency, and Accountability: A Discourse Analysis of AI Accessibility Overlays," argues that the AccessiBe case reveals how automated accessibility solutions erode the agency of disabled users. These solutions exclude users from design, interfere with the assistive technologies they already rely on, and diffuse accountability so widely that no party is meaningfully held responsible when harms occur. The paper uses discourse analysis to trace how AccessiBe, the FTC, and disability advocates each constructed the meaning of accessibility differently, and how those competing framings shaped real outcomes for disabled users. AccessiBe's marketing positioned accessibility as a technical compliance problem solvable through one line of code, removing the expertise of disabled users and redefining access as an automated input rather than a human process. The FTC's enforcement action framed the failure as deceptive marketing rather than a disability rights violation, leaving the deeper structural harms largely unaddressed. The National Federation of the Blind's 2021 resolution condemned AccessiBe's product as an active source of harm rather than an imperfect solution. The paper concludes that accessibility cannot be achieved through automation applied after the fact, and that disabled users must be embedded throughout the development process rather than treated as a compliance problem for an algorithm to solve.
Concluding Reflection
Working on both projects simultaneously forced me to make real versions of the design choices my STS paper critiques. Building Dream made the AccessiBe critique feel concrete rather than abstract. When I was deciding how Dream would handle page navigation, especially whether to rely on DOM structure or visual recognition, I was making exactly the kind of design choice the STS paper shows AccessiBe got wrong. Choosing visual recognition was partly a technical necessity, since most sites lack proper markup, but the STS research helped me see that it was also a political choice. A system that works on inaccessible sites without requiring them to become accessible does not pressure developers to fix the underlying problem. It treats the symptom. The tension between user-side intervention and structural change is one I was only able to articulate clearly because the STS paper forced me to examine what accessibility reform actually requires.
The STS research also sharpened how I thought about user control in Dream's design. One of the paper's central findings is that AccessiBe degraded agency by making modifications to page structure that disrupted the screen readers blind users had already learned to trust. Dream faces a version of the same risk. An AI that takes over web navigation can override the strategies a user has developed for getting around a site they know well. That concern shaped how I thought about Dream's follow mode and the importance of keeping the user informed about what the AI is doing at each step. Working on the technical project gave the STS argument about agency a real-world application. It was not just a theoretical critique but a design problem I had to navigate. Thinking through the STS argument gave me language for what was at stake in choices I might otherwise have treated as purely implementation details. The two projects pushed each other in ways that ended up making both stronger.
