{"slug": "accesspatch-breaking-down-web-barriers-for-people-with-disabilities", "title": "AccessPatch: breaking down web barriers for people with disabilities", "summary": "A developer built AccessPatch, a Chrome extension that uses Gemma 3 4B running locally through Ollama to propose accessible names for web controls and repair mouse-only elements so they can be reached by keyboard navigation. In recorded Windows Narrator tests, an email field announced only its placeholder before the repair and \"Email address. Edit.\" after, while a mouse-only menu skipped by Tab became reachable and announced as \"Open navigation menu\"; an ambiguous icon stayed unnamed when the model had insufficient evidence. Changes are applied locally to the user's copy of the page, leaving the site's server untouched and allowing repairs to be undone.", "body_md": "*This is a submission for the [Hacktoberfest Weekend Challenge: Build for a Friend](https://dev.to/challenges/hacktoberfest-weekend-2026-10-01).*\n\nA visually impaired friend had told me about accessibility issues he encounters online. A website can look perfectly usable while leaving someone who relies on a screen reader or keyboard unable to understand or reach its controls.\n\nWhen I saw this challenge, I wanted to explore whether local AI could help reduce those barriers directly in the browser. That became **AccessPatch**.\n\nIn my test recording, Windows Narrator reaches a search control and announces: “Search the catalog region. Button.” A sighted user can recognize the magnifying glass. The screen reader announces a button without a name. The next barrier is quieter: a clickable menu that keyboard navigation skips entirely.\n\nAccessPatch is a Chrome extension that repairs supported controls in the user's copy of a page. It uses **Gemma 3 4B, running locally through Ollama**, to propose meaningful accessible names. A separate set of rules adds keyboard focus and activation to supported mouse-only controls.\n\nThere are three modes:\n\nThe website's server stays untouched. Changes are local to the browser and can be undone.\n\nThe 2:26 demo includes genuine Windows Narrator audio from my recorded test session.\n\nThe most useful comparisons start around **1:33**:\n\n| Control | Before | After | \n|---|---|---|\n| Email field | Narrator reads the placeholder: “Name at example.com. Edit.” | “Email address. Edit.” | \n| Mouse-only menu | Tab skips the control. | The repaired menu is reachable and announced as “Open navigation menu.” | \n| Unexplained diamond icon | “Button.” | It stays unnamed because the model has insufficient evidence. | \n\nThe video also shows a search-field repair on [Deque's deliberately inaccessible training site](https://webtestingcourse.dequecloud.com/). Both that page and my local lab are practice fixtures. The recording establishes behavior in these examples; broader user testing is still ahead.\n\n**Meaningful control names. Keyboard access. Repairs on your terms.**\n\n[**Watch the demo**](https://youtu.be/FaEiTva-fQ8) · [** Download the extension**](https://github.com/turazashvili/accesspatch/releases/latest) · [** Install guide**](https://github.com/turazashvili/accesspatch/docs/INSTALL.md) · **How it works**\n\nAn icon can look obvious while a screen reader announces only **“button.”** A clickable element can respond to a mouse while the Tab key skips it.\n\n**AccessPatch** is a Chrome extension that uses **Gemma 3 4B locally through Ollama** to propose accessible names for supported web controls. Explicit keyboard rules repair a conservative class of mouse-only custom buttons. Changes are applied to your copy of the page and can be undone.\n\nThe demo contains actual Windows Narrator before/after audio from a recorded test session:\n\n| Control | Before | After | \n|---|---|---|\n| Email field | Placeholder announcement | **“Email address. Edit.”** | \n| Mouse-only menu | Skipped by keyboard navigation | Reachable and announced as **“Open navigation menu”** | \n| Ambiguous icon | Unnamed button | Remains unnamed when evidence is insufficient | \n\n**[Download AccessPatch v0.1.0](https://github.com/turazashvili/accesspatch/releases/tag/v0.1.0)** · [Installation guide](https://github.com/turazashvili/accesspatch/blob/main/docs/INSTALL.md)\n\nThe release includes an unpacked extension ZIP and a SHA-256 checksum. Extract the ZIP and select its directory through Chrome's **Load unpacked** option.\n\nThe repository contains the unpacked Manifest V3 extension, the before/after lab, automated tests, and a model evaluation script. The extension has no production package dependencies or build step.\n\nFor the local setup:\n\n```\nollama pull gemma3:4b\nollama run gemma3:4b\n```\n\nThen load the `extension` directory through Chrome's **Load unpacked** option and configure:\n\n```\nAPI base URL: http://localhost:11434/v1\nModel:        gemma3:4b\nAPI key:      empty for a normal local Ollama setup\n```\n\nWebsite access enables visit scanning. Ollama may also need the extension's specific origin in its `OLLAMA_ORIGINS` allowlist. Same-computer use works with the server bound to localhost.\n\nThe content script finds visible candidate controls and extracts nearby text, labels, placeholders, and icon metadata. Entered form values, editable text, script contents, and URL query strings are excluded from the scan payload. Nearby page prose can still contain sensitive information.\n\nGemma receives **one unnamed control per request** and returns a proposed name, a quoted piece of evidence, and an explanation in schema-constrained JSON. The extension validates the target, output bounds, and evidence before using the proposal.\n\nFor example, a supported proposal becomes:\n\n```\n<button aria-label=\"Search catalog\">\n  <!-- Existing icon and application behavior remain in place. -->\n</button>\n```\n\nThe inference input is text and metadata. This version does not send screenshots to a vision model.\n\nThe menu fixture is a clickable `div`. The keyboard repair adds a button role, a tab stop, and listeners that invoke its existing click action. Enter activates on keydown; Space activates on keyup. Repeated keydown events do not repeatedly activate the control.\n\nThat behavior is implemented in extension code. Gemma supplies the proposed accessible name. It never supplies executable repair scripts.\n\nI started with Gemma 1B. The first prompt produced responses that echoed the input instead of returning repairs. Constraining the JSON shape solved the format problem, but the smaller model still guessed labels and followed instructions embedded in page context.\n\nSeparating evidence fields, adding examples of abstention, and sending one target per request helped. I then compared the final prompt across both models:\n\n| Model | Synthetic checks passed | False labels on ambiguous/instruction-only cases | \n|---|---|---|\n| Gemma 3 1B | 11/16 | 3 | \n| Gemma 3 4B | 16/16 | 0 | \n\nThis is a small synthetic smoke test. It guided the choice of 4B; real-world accuracy and resistance to malicious page text need wider evaluation.\n\nProposals are bound to actual elements and a snapshot of their context. A changed control or navigation can invalidate them. Undo restores only attributes that still match AccessPatch's applied values, preserving later changes made by the website.\n\nThe project has **22 passing automated tests**, covering output validation, private form-value exclusion, keyboard activation and cleanup, stale targets, navigation, automatic/debug modes, and stopping auto-apply when the user pauses during inference.\n\nThe prototype focuses on accessible names and a conservative class of custom-button keyboard repairs. A scan covers up to 24 candidate controls. It works in the top-level document and does not currently generate image descriptions or repair canvas interfaces, cross-origin frames, shadow-root content, or complete custom-widget interaction patterns.\n\nArbitrary same-route rerenders can require another scan. Model proposals can still be wrong, including in Automatic mode. Debug provides a way to inspect them and undo changes.\n\nAn accessibility repair model sees text near the controls someone is using. On account pages or forms, that context can be personal even when typed values are excluded. Running Gemma locally keeps the analyzed context on the user's machine in this configuration.\n\nOpen weights also let me test model sizes against the same tasks, choose the one that behaves better, and keep the model replaceable. The extension accepts configurable OpenAI-compatible endpoints, so its repair pipeline can use another compatible model or runtime.\n\nLocal inference can continue without access to a remote inference API once the model is installed. The websites themselves still need whatever connectivity they normally require. There is no per-request inference-service bill in the local setup; hardware and electricity remain costs.\n\nThe practical benefit is control over where inference happens, which model performs it, and how its proposals become page changes.\n\nMy goal is to give people who encounter inaccessible interfaces more control over their browsing experience. AccessPatch starts with two concrete barriers: unnamed controls and mouse-only buttons. The next step is testing it with people who rely on assistive technology and learning which repairs genuinely help them complete everyday tasks.\n\nI used OpenCode during implementation and testing. The development process included inspecting Chrome's accessibility tree, exercising real keyboard events, and checking model responses against the synthetic fixtures.\n\nGemma 3 4B performs the project's accessible-name inference locally through Ollama. Its evidence-grounded proposals become bounded, reversible DOM repairs. The model comparison and recorded demo show its role in the finished extension.\n\nThanks to the Gemma and Ollama teams, and to Deque for the accessibility practice site shown in the demo.\n\nAI tools assisted with the implementation and preparation of this write-up.", "url": "https://wpnews.pro/news/accesspatch-breaking-down-web-barriers-for-people-with-disabilities", "canonical_source": "https://dev.to/axrisi/accesspatch-breaking-down-web-barriers-for-people-with-disabilities-5dk3", "published_at": "2026-10-02 10:32:34+00:00", "updated_at": "2026-10-02 10:37:59.827344+00:00", "lang": "en", "topics": ["artificial-intelligence", "large-language-models", "ai-tools", "ai-products"], "entities": ["AccessPatch", "Gemma 3 4B", "Ollama", "Chrome", "Windows Narrator", "Deque", "Hacktoberfest"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/accesspatch-breaking-down-web-barriers-for-people-with-disabilities", "markdown": "https://wpnews.pro/news/accesspatch-breaking-down-web-barriers-for-people-with-disabilities.md", "text": "https://wpnews.pro/news/accesspatch-breaking-down-web-barriers-for-people-with-disabilities.txt", "jsonld": "https://wpnews.pro/news/accesspatch-breaking-down-web-barriers-for-people-with-disabilities.jsonld"}}